Introduction to branching

This forum is currently in read-only mode.
  • Quite often people ask one question (well, the phrase changes, but it boils down to this): "Why isn't the state switched?"

    The answer hides in the way Construct works. The event sheet is executed in a loop. The start of the loop is a new tick, then every event is executed until the end of the sheet. The changes are reflected and then the next iteration starts.

    Here is a rough sketch of what is going on during one tick (I'm no professional, so this is in no way a real flow chart, but it makes the progress more visible and understandable):

    As you can see, changes you make with actions are updated, but not reflected until the whole sheet is processed. "But how does this prevent my state being switched?", you may ask. Let's take a simple example that will make it clearer.

    Start Construct, create a new Direct-X game, insert a sprite, the mouse&keyboard object and a textbox. Clear the text of the textbox. In the event sheet, do this:

    Now have a look at the diagram. Let's say the sprite is clicked. Now this is snapshotted as well as the fact that the current text of the textbox is "".

    The event sheet is executed. There is only one event. The snapshot says "Yes, the sprite is currently clicked on", so the action is performed. The text of the textbox is now updated to "hello world", but we don't see any changes yet.

    There was only one event so the changes are now reflected, a new tick begins and the new text will be drawn by the gpu in this new tick. This is important to keep in mind.

    Now let's see another example. We want the text to be changed to "hello world" on one click and changed to "" on the other and so on. Straight forward, you may think this is the solution:

    Again, let's have a look at the diagram. The first event matches the click (remember the snapshot). The second condition means: Execute only if the current text is not "hello world". According to the snapshot, the text currently is "" so the condition is met.

    Both the trigger and the condition result to true and the action is performed. The text of the textbox is now updated to "hello world". But remember, the event sheet is still executed, a new tick has not begun yet, so we don't see any changes!

    There is a second event, we are going back to "execute sheet". The click is still part of the snapshot, "On Left Clicked on Sprite" still results to true. But the text in the snapshot is updated by the first event and is now "hello world". Uh, we met the condition and as both the trigger and the conditon result to true, the action is perfomed. The text of the textbox is now updated to "".

    This was the last event, the changes are reflected, a new tick starts, and the gpu draws the new text. But hey, the new text is "". We will never see the change to "hello world", because it is changed again to "" within the execution of the sheet!

    But how can this be solved? The easiest way is to use branching:

    If condition is met do something, else do something different. This is done in Construct this way:

    The difference is that now the text is only tested once for both actions. We can't do any wrong changes to it.

    "Is there another way to get this working? I'm not familiar with branching." Well, yes, but the other ways are less efficient and less elegant. Look at this example:

    It works, but uses an additional global and more lines of code. You should definitely consider branching.

    I hope this will help you with switches and such. I know the text is not nice to read, but together with the images it should make sense to you.

  • This is really nice, and the information about snapshots is something I'll file away for future debugging!

    I had a vague understanding of sub-events from (very scant) previous programming experience, but this helps solidify it in my mind.


  • Indeed, this has been written very nicely and is good to understand.

    Thanks for posting this.

  • Nice post, tulamide. I've seen this issue pop up a lot as well.

    The power of ELSE is not to be underestimated. It provides an elegant way to make two set of actions mutually exclusive, so that only one set will be executed per test.

    And it seems to work nicely in the newest 'unstable' (possible next release candidate) build.

  • Yeah I will have to look more into this myself... I am guilty of all counts of making too many events... one for "yes" and one for "no".

    I find using Else difficult... but this tutorial should help a fair bit.

    Thanks for the post!


  • I love using else.

    However, I don't think I have any excuse for this. Well, actually I do have one favourable thing to say about it: It works.

    Open in a new tab, it's huge. (And pardon the artifacts - I reduced the quality in favour of filesize reduction).

    E: Forgot to explain a little

    I had a major logic problem with arranging the little dudes at the bottom of the screen. They just wouldn't play nice for every particular combination of positions that they could be in when the final count is done. I've tried 3 major revisions of this and nothing ever worked for all combinations.

    This was the brute force approach where any specific arrangement that would cause problems is handled slightly differently to the general approach.

    If nothing else, it should provide some amusement.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • This is essential for newcomers, thanx tulamide!

    Suggest placing it (as an important hint) in the Wiki !

  • Great tutorial for beginners!

    The else condition is fantastic! However, i actually found the "bad" version most interesting. Before i used Else i had similar workarounds, but even worse, so if i for some reason don't get else to work now at least i have a clean (more or less) workaround to fall back on.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)