Video Tutorial: Conditional Logic in GameSalad's Expression Editor

Armelline

I intend to touch on this briefly when I do my presentation at August's meet-up, but this topic is too big to go into in any real kind of depth during that talk. So what I thought I'd do is a series of videos about conditional logic. This is the first part.

I actually recorded this video three times. First time last night, but I then realised after finishing that I'd not turned on sound recording. So I recorded it again this morning, and having had the practice of doing it before I think I absolutely nailed it. But between last night and this morning I'd not actually turned the audio recording on... So this is attempt three, and by this point I was getting a little impatient, so sorry if that comes across in the video!

Anyhow, Conditional Logic in GameSalad's Expression Editor:

Part 2 will look at more complex logic, and Part 3 will look at some helpful real-world uses of this type of logic.

MentalDonkeyGames

Great stuff again, thanks!

Icebox

I didn't know you can do this ! thanks alot !

The_Gamesalad_Guru

I wonder if this type of streamline logic has a positive effect on performance. I guess it depends on how GS sorts out behavior logic when published.

RThurman

@Armelline -- Thanks for such a clear tutorial on conditional logic in the expression editor!

I think few people really understand how powerful the expression editor really is. And even fewer understand that the ability to write expressions is one of GameSalads most important features!

MentalDonkeyGames

I agree with @RThurman
When i first started using GS, i avoided the expression editor, because it confused me.

Now i can´t live without it

Armelline

@RThurman said:
I think few people really understand how powerful the expression editor really is. And even fewer understand that the ability to write expressions is one of GameSalads most important features!

This is something I hope to at least party change in my upcoming talk about the Expression Editor!

robertkdale

@Armelline Thank you for sharing! I will be using the expression editor more!

tintran

great tutorial. Thanks

The_Gamesalad_Guru

@Armelline said:
This is something I hope to at least party change in my upcoming talk about the Expression Editor!

Is this for a meetup. I'll have to attend that one. This is something I'll be using more and exploring myself. I could see this as a big plus for multiplayer applications to slim down the code.

BlackCloakGS

The next GameSalad meetup is all about the expression editor

Armelline

@The_Gamesalad_Guru said:
Is this for a meetup. I'll have to attend that one. This is something I'll be using more and exploring myself. I could see this as a big plus for multiplayer applications to slim down the code.

The meetup is going to focus more on the standard functions, log10, ln, magnitude, sin/cos etc.

I plan on looking briefly at conditional logic, but my focus is going to be on functions. There's two more parts coming for this video series though!

kolabo

Very interesting. Watched it twice. Hope to make it to the next meetup.

Lovejoy

@The_Gamesalad_Guru said:
I wonder if this type of streamline logic has a positive effect on performance. I guess it depends on how GS sorts out behavior logic when published.

This would be a great thing to know for sure.

neoman

Fantastic stuff as always! Thanks for sharing. We will all be coding in LUA very shortly after watching your conditional logic videos ... ha ha Cheers and no you didn't sound impatient ... Well done on take 3. I am also keen like others to know if this has performance improvements .... It will certainly be a time and space saver once it is mastered ...

Armelline

@neoman Thanks! I'm going to try to get part 2 done today, looking at some more complicated examples!

Braydon_SFX

Great content! Many people are unaware of the abilities inside the expression editor - glad I can point them to a clear tutorial now!

Hopscotch

Awesome @Armelline !

pHghost

@Braydon_SFX said:
Great content! Many people are unaware of the abilities inside the expression editor - glad I can point them to a clear tutorial now!

Is there a list of all the capabilities (syntax)? I use the expression editor quite a lot, but this video was very revealing!

JSproject

@Armelline Interesting stuff, I did not know that it was possible to use the expression editor to write conditions that handle "otherwise" logic in the way that you demonstrated in your video. With that said I highly doubt that doing it that way would offer any performance gain compared to doing it the normal way via otherwise sections.

Armelline

@JSproject said:
With that said I highly doubt that doing it that way would offer any performance gain compared to doing it the normal way via otherwise sections.

It's not so much about performance gain as faster writing of logic. Definitely something for more experienced users though who are happy looking at something like

(self.Doubler==true)and((self.Value==0)and(1)or(self.Value==1)and(10)or(20))or((self.Value==0)and(1000)or(self.Value==1)and(999))

and knowing what it's supposed to do! When you're comfortable with writing conditions by hand it can really increase the speed you can make something - quite dramatically in fact!

I have more tutorials planned and none of them are for the light of heart

JSproject

@Armelline said:

Your explanations are great and easy to understand and yes, I can imagine that it is faster to build logic that way but at the expense of increased risk of introducing an error (thus wasting time debugging). Personally I also like to have a direct visual overview via the otherwise sections. If there would have been performance to gain from this I would likely convert to doing it this way though. Anyways, having different options are always good and I will watch your upcoming videos on this theme.

pHghost

One thing that is worth mentioning is that the current implementation of the expression editor, with a single line of text often makes it quite hard to have a good overview of the whole block of code, thus making it potentially difficult looking for mistakes as @JSproject mentions.

@Armelline is there a resource somewhere outlining the different functions (in addition to the 'and' + 'or' you introduced) that can be used in the expression editor?

Armelline

@JSproject said:
Your explanations are great and easy to understand and yes, I can imagine that it is faster to build logic that way but at the expense of increased risk of introducing an error

Absolutely. I'll be looking at specific cases where I think this is a better way of doing things - without introducing too much risk of errors - in part 3 of my video series.

Things like when you want to concatenate a boolean to text. There are some real-world uses where this saves time and introduces very little extra risk.

@Armelline is there a resource somewhere outlining the different functions (in addition to the 'and' + 'or' you introduced) that can be used in the expression editor?

Not that I'm aware of. It would be difficult to make such a document, though.

You'd need to cover:

• All the functions (there's quite a few)
• Using operators
• Conditional logic
• Concatenation

Probably other stuff too that's escaping my mind. Between the written tutorial I'm working on, the presentation I'll be doing at the start of August, these videos, and my display text written tutorial, I hope to have it covered, though.

pHghost

@Armelline said:
Not that I'm aware of. It would be difficult to make such a document, though.

You'd need to cover:

All the functions (there's quite a few)
Using operators
Conditional logic
Concatenation

Fair enough. I was just wondering (and hoping).

neoman

@pHghost said:
Is there a list of all the capabilities (syntax)?

Check out the link below. It might help

http://lua-users.org/wiki/TutorialDirectory

Socks

@Armelline said:
I intend to touch on this briefly when I do my presentation at August's meet-up, but this topic is too big to go into in any real kind of depth during that talk. So what I thought I'd do is a series of videos about conditional logic. This is the first part. . . . .

Brilliant !!

Socks

@Armelline said:
It's not so much about performance gain as faster writing of logic.

Yeah this is something that I was thinking about too, with the recent(ish) discussion on nested rules, preventing GS from continuing to evaluate conditions it needn't evaluate (given the first condition fails) I would be surprised if GS would only partially parse an equation (I think we can all agree this in very unlikely to be the case), so these more involved equations might be less efficient than splitting the same conditions into separate nested rules - but sometimes, especially when a game is not particularly demanding on the processor this is way neater way to construct rules, and not just because it's faster, but it's much easier to look through 3 or 4 behaviours rather than 16 rules with various conditions and otherwise sections, so it wouldn't just be faster to produce, but faster to scan and correct and search for bugs and so on.

Socks

@pHghost said:
One thing that is worth mentioning is that the current implementation of the expression editor, with a single line of text often makes it quite hard to have a good overview of the whole block of code, thus making it potentially difficult looking for mistakes as JSproject mentions.

Yep, it would be great if the expression editor opened up something like a blank text file, rather than a one line window, and with all the functions as little buttons at the top, so no scrolling down for magnitude or vectorToAngle - in fact I'd be happy if hitting the expression 'e' opened an external application where you could do all this - and closing it/hitting save wrote whatever you'd entered into the expression window (a little like the way Unity handles writing code by passing you over to an external application), I'm only really saying this as I imagine it would be a way around having to reformat (if that's the right word) Creator's code base to add in a new expression UI . . .

Also . . auto complete would save having to dig out expressions from drop down lists, start to type 've . . . ' and 'vectorToAngle' auto completes, start to type in 'ma . . ' and magnitude autocompletes, with the values in the brackets highlighted ready for you to type over.

Armelline

@Socks said:
I would be surprised if GS would only partially parse an equation (I think we can all agree this in very unlikely to be the case), so these more involved equations might be less efficient than splitting the same conditions into separate nested rules

We know how these are run in that regard - it will evaluate until the condition is met. So if, for example, I make one that says:

( game.Touches.Active.Touch 1 ==false)and(1)or( game.Touches.Active.Touch 2 ==false)and(2)or( game.Touches.Active.Touch 3 ==false)and(3)or( game.Touches.Active.Touch 4 ==false)and(4)or( game.Touches.Active.Touch 5 ==false)and(5)or( game.Touches.Active.Touch 6 ==false)and(6)or( game.Touches.Active.Touch 7 ==false)and(7)or( game.Touches.Active.Touch 8 ==false)and(8)or( game.Touches.Active.Touch 9 ==false)and(9)or( game.Touches.Active.Touch 10 ==false)and(10)or( game.Touches.Active.Touch 11 ==false)and(11)

and game.Touches.Active.Touch 1 is false, the expression will stop being evaluated immediately after that condition, so all that will be evaluated is:

( game.Touches.Active.Touch 1 ==false)and(1)

The same, of course, is true of the nested rules. All these are is those, but written out. You can, as I'll look at in my next video, add multiple conditions like with rules, and then both are again treated in exactly the same way.

Unless GameSalad is being naughty in how it evaluates (graphical) rules, there should be no difference at all in performance. Maybe in the Creator's preview, but even then I'd be surprised. When you send your project to GS to be compiled, they take the rules you've written, and convert it to C or whatever it ends up in. Getting from the rules to the actual raw code will happen exactly the same whether you've used this type of condition or graphical rules. So the only place you're likely to see a performance increase is in Creator, where deeply nested graphical rules can be a little slow, even with the recent speed increases.

Socks

@Armelline said:
. . . the expression will stop being evaluated immediately after that condition . . .

Interesting ! I would have thought that given that a list of conditions (non-nested) in a rule are all parsed - even if the initial condition is failed - that an even more self-contained set of conditions would also be subject to the same approach, but if the equation is evaluated piecemeal then that makes this method even more valuable.

The obvious corollary here is how have you been able to establish this is the case - common-sense/logic/my-brain says you are right, but logic said I was right about multiple conditions in a rule not continuing to be checked after one has failed and it turned out I was wrong (Hopscotch gave a great under-hood-explantion), did you test this ?

I can think of very obvious test scenarios.