In what order everything updates during a tick?

  • I posted this bug report and it was not really a bug. I misunderstood how everything is processed during a tick.

    From what I understand from Ashley's answer to my bug report is that when I access a system variable, I do it before any behaviours. So if a behaviour change any system variable it will do it near the end of the tick and after an event accessed it. This way the new value can be read on the next tick. It's good to know. Now I'm curious of how everything is linked together during a tick. Specifically: In what order everything updates during a tick?

    Note: I already know what the manual says about events. What I want to know is more in depth (I supposed).

    Thanks!

  • Events run top to bottom, unless its a function.

  • As I wrote in my first post, I did read the manual. So yes, I know already what is explained there. I haven't find what I want to know in the manual. If my answer can be found there, I'll be happy to follow a link and read more.

    Construct is mainly a set of events, plugins, objects and behaviors. Events run top to button but triggers runs when they are triggered and functions when they are called. Simple.

    To clarify what I'm looking for:

    Let's say an object have a behavior. At what time during a tick this behavior will be process? Before the events sheets? During the events sheets? After the events sheets? Before drawing to screen? While drawing to screen? After drawing to screen? ...

    When a trigger is triggered. This event is process at the time it triggered? Before the events sheets on the next tick? After the events sheets on the next tick? ...

    I understand it's not an easy question. Maybe there is a flowchart somewhere. Maybe it's super secret classified Scirra enterprise stuff. Or maybe no body knows.

  • I cannot answer your question, but maybe you can get some answers yourself by using the debug mode and breakpoints in C3 runtime.

    This way you can exactly see at chosen points when a value is changed, for example.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • More than secret, it actually is hard to answer as there is no set "flowchart".

    Triggers will happen at different "execution" time, depending on the plugin, the behavior, the nature of what's triggered, functions are "false triggers", and even for the same trigger (for example a gamepad button press) this can happen at different time.

    I guess Ashley could give a bit more details to clarify.

  • The answer is actually pretty complicated: different behaviors update at different times, both before and after events run, both before and after relative to other behaviors and plugins, depending on the specific plugin or behavior. I also think it's something games should avoid deliberately depending on, since it's implicit and inconsistent across addons.

  • Yeah I think behaviors are great to get you started and understand how the engine works and how to make games but the meat of construct 3 is it's event system and you can use events to create much more efficient games because the behaviors are made to work in pretty much every scenario but you can use events to make your game tailor made for your needs, instead of always relying on solids and requesting features for the solid behaivor you can make your own !!! The possibilities when creating your own are infinite !! Good luck out there !!

  • I think the biggest thing to watch out for is the fact that plugs, and behaviors will run quicker than events since there's less for them to look up. Its way less noticeable in the C3 runtime however.

  • In c2 here is the flow

    construct.net/en/forum/extending-construct-2/javascript-sdk-32/order-of-update-calls-91514

    So as said above when a plugin/behavior runs depends how things are implimented.

    However as a rule of thumb I go by a simplified flow:

    1. Run plugins and behaviors

    2. Run events

    3. Run certain plugins and behaviors

    4. Draw

    5. Repeat

    For the most part most plugins and behaviors run in 1, but a few (such as drag drop as well as part of the platform behavior) run in 3.

    I guess over time I’ve created a mental list about the exceptions or I just recreate the behavior with events so I know exactly when it runs.

    Guess I should also read your big report.

    -cheers

    Edit:

    Read your bug report. That’s a bit different. Most actions are immediate in that they change things there and then. Some actions, probably for performance reasons, delay actually updating till that plugin is run or drawn.

    Anyways with the tiledbackground offset being delayed I can’t say I’ll use it much. I do my best to avoid off by one frame things like that.

  • You are all awesome!

    Even if there is no clear and definite answers, I do understand better how everythings is tied together.

    Ok, so here are key points I could outlines from your answers (in no specific orders):

    • There is no secrets (i knew it! :) ).
    • Games should not depends on addons processing timing. (I don't totally agree but I admit it's definitly good wisdom for majority of cases.)
    • There is no standardize order in which any plugins, behaviors and triggers will happens.
    • Behaviors updates in any order before and after events. It depends on how they are implemented.
    • Behaviors can be hand made with events and it's sometimes a solution. ( Good idea! )
    • Draws happens after everything.
    • I'm not sure if the info I found in the link shared by R0J0hound is still valid with C3 runtime but it kind of confirm everything.

    Did I slip a mistake in my list? Did I forgot a point?

    Alright! I've got something to work with. I guess I'll go deeper and read the SDK manual now. And maybe dig C3 and see what's under the hood.

    Thanks to all of you!

    I appreciate it.

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