Is there a list of Conditions that work as "Every Tick"?

0 favourites
  • 6 posts
From the Asset Store
Template for scrollable list, fully documented in comment and video
  • I am getting obsessed with programming my games as much "mobile friendly" as possible. (Severe trauma from the last 2 weeks when I'm failing miserably in porting a simple game to mobile, and worried about my other games that are filled with potential memory consuming events)

    I know that besides the "Every Tick", there are others that constantly checks every tick if the related objects reaches or not their trigger conditions. For example checking collisions

    Is there any list available of these conditions? it would be nice to have one, together with the best practices tutorials and articles sprinkled over Scirra's website/forum.

  • I use check every 0.1 second in some events.

    It's more better than every tic.

  • Leaving the condition blank also causes "every tick related events I guess"

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Everything that isn't a trigger runs "every tick", if it's a top-level event.

  • I am getting obsessed with programming my games as much "mobile friendly" as possible. (Severe trauma from the last 2 weeks when I'm failing miserably in porting a simple game to mobile, and worried about my other games that are filled with potential memory consuming events)

    I know that besides the "Every Tick", there are others that constantly checks every tick if the related objects reaches or not their trigger conditions. For example checking collisions

    Is there any list available of these conditions? it would be nice to have one, together with the best practices tutorials and articles sprinkled over Scirra's website/forum.

    Basically, every condition other than true triggers (like on created, on function, on start of layout), is checked every tick, the goal is to reduce the calculations needed by the device, collision is a pretty heavy condition compared to check if a variable is equal to something, or if a grouo is active, or something else, and even more if the number of collision to check is big, deactivating collisions and behaviors on objects that aren t on screen (or that don t need them active at a given situation) can help, not abusing of loop also is mandatory (you can still use them in cases they are really needed of course), lowering the number of points in the object hitbox can help too (pixel perfect like collision is rarely needed), some object can have on collision active only one tick out of two without breaking the game, at the end, a synthesis is:

    If you are using a behavior, do you really need all it s functionnalities, and if not, can you reproduce what is needed in events only? If so try it

    Keep calm, make a scenario in your head, then read the event sheet yourself, from top to bottom, reading the includes too, with that particular scenario, if somethings seems redundant, or looks line it could be avoided, maybe it is indeed.

    Functions are great, and can make the code look cleaner, and so is easier to edit and optimise.

    Groups help organize events, and they can be deactivated and activated by events, learn what is always needed, and what is only conditionnal, for exemple, the ennemi AI is only active if the ennemy exist, and in some cases, if it is on screen, you could play around with that.

    Maths can be pretty heavy when done a lot of times, so try to simplify the calculations if possible.

    For a clean work, do not use global variables only, instances variables for instance, local variables for what is only needed in a group for exemple.

    Includes can be dragged inside sub events, which can help deactivating an entire event sheet when for exemple, the game is paused.

    Workarounds are a bad pratice and so, if needed, should always be isolated inside functions and such, since they can broke pretty much from one version to another.

    It is only a concise and non exhautive list of how I do in C2 that works.

  • > I am getting obsessed with programming my games as much "mobile friendly" as possible. (Severe trauma from the last 2 weeks when I'm failing miserably in porting a simple game to mobile, and worried about my other games that are filled with potential memory consuming events)

    >

    > I know that besides the "Every Tick", there are others that constantly checks every tick if the related objects reaches or not their trigger conditions. For example checking collisions

    >

    > Is there any list available of these conditions? it would be nice to have one, together with the best practices tutorials and articles sprinkled over Scirra's website/forum.

    >

    Basically, every condition other than true triggers (like on created, on function, on start of layout), is checked every tick, the goal is to reduce the calculations needed by the device, collision is a pretty heavy condition compared to check if a variable is equal to something, or if a grouo is active, or something else, and even more if the number of collision to check is big, deactivating collisions and behaviors on objects that aren t on screen (or that don t need them active at a given situation) can help, not abusing of loop also is mandatory (you can still use them in cases they are really needed of course), lowering the number of points in the object hitbox can help too (pixel perfect like collision is rarely needed), some object can have on collision active only one tick out of two without breaking the game, at the end, a synthesis is:

    If you are using a behavior, do you really need all it s functionnalities, and if not, can you reproduce what is needed in events only? If so try it

    Keep calm, make a scenario in your head, then read the event sheet yourself, from top to bottom, reading the includes too, with that particular scenario, if somethings seems redundant, or looks line it could be avoided, maybe it is indeed.

    Functions are great, and can make the code look cleaner, and so is easier to edit and optimise.

    Groups help organize events, and they can be deactivated and activated by events, learn what is always needed, and what is only conditionnal, for exemple, the ennemi AI is only active if the ennemy exist, and in some cases, if it is on screen, you could play around with that.

    Maths can be pretty heavy when done a lot of times, so try to simplify the calculations if possible.

    For a clean work, do not use global variables only, instances variables for instance, local variables for what is only needed in a group for exemple.

    Includes can be dragged inside sub events, which can help deactivating an entire event sheet when for exemple, the game is paused.

    Workarounds are a bad pratice and so, if needed, should always be isolated inside functions and such, since they can broke pretty much from one version to another.

    It is only a concise and non exhautive list of how I do in C2 that works.

    Great tips, thanks Aphrodite!

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