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

Discussion and feedback on Construct 2

Post » Tue May 13, 2014 3:20 pm

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.
B
12
S
6
G
3
Posts: 102
Reputation: 3,937

Post » Tue May 13, 2014 3:43 pm

I use check every 0.1 second in some events.
It's more better than every tic.
B
60
S
10
G
10
Posts: 1,013
Reputation: 9,155

Post » Tue May 13, 2014 3:48 pm

Leaving the condition blank also causes "every tick related events I guess"
Image
Check out our start-up and configure your own helmet in true 3D.
B
44
S
11
G
11
Posts: 1,154
Reputation: 9,978

Post » Tue May 13, 2014 3:56 pm

Everything that isn't a trigger runs "every tick", if it's a top-level event.
ImageImageImage
B
71
S
21
G
231
Posts: 3,691
Reputation: 129,358

Post » Tue May 13, 2014 4:05 pm

pcfernandesjr wrote: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.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Wed May 14, 2014 1:16 pm

Aphrodite wrote:
pcfernandesjr wrote: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!
B
12
S
6
G
3
Posts: 102
Reputation: 3,937


Return to Construct 2 General

Who is online

Users browsing this forum: Google [Bot], tarek2 and 25 guests