Worse advice you can give to a mobile dev.
Don't you see this forum is constantly filled by complaints of poor performance? 99% of the time its because mobile devs failed to optimize their games ground up.
Even for the PC, it's best practice to always optimize your game and design it around extracting peak efficiency. This is especially true for mobiles, even if your game runs 60 fps. If its efficient, it runs 60 fps while using less CPU cycles, resulting in less "battery draining" or "overheating devices".
ps. Setting A = B every tic doesn't matter much, but repeat those wasteful events enough, it becomes bloated, poorly optimized and then it truly matters.
It wasn't my intention to say that optimization on the whole should be ignored. My response was towards this tendency of "blindly optimizing" the game logic, which causes folks to spend eons tweaking their events, without taking care to develop a genuine understanding of what truly makes games performant.
The way I see it, there are two extremes in high-level development, both which fail to capture reality: The first ignores optimization altogether, thinking the framework will handle it all. The second is obsessive compulsive, and convolutes the code in the name of optimization and peak performance, ignoring so much of what the framework is already doing behind the scenes to make it easier for developers.
Obviously, there's a wiser approach that strikes a balance and gives peace of mind, allowing you to use your framework the way it was intended to be used for code clarity and organization, and yet get desirable performance out of your game. It doesn't do away with optimization, but uses genuine knowledge (as opposed to simplistic philosophy) to decide what to spend time on, and what things to let the framework handle as it already does so well.
In the spirit of discovering this wiser approach, we could say that villainizing 'Every Tick' events solely on the basis of them being 'Every Tick' events is blind optimization of logic, which in this case ignores Construct 2's already well-optimized logic engine and steals some emphasis away from real performance culprits, notably graphics intensive operations. You could spend a week hacking 10 events into a single efficient one, but the wisdom of reducing readability and maintainability for the few percentage points of performance you gain would be questionable. To quote Ashley from the "Optimisation: don't waste your time" blog post:
[quote:1egqpwd8]
Our profiling has shown it's not unusual for even a fairly complex game to spend 10% of the time on the logic, and 90% of the time on rendering - even when hardware accelerated! In other words, if you're not getting 60 FPS, the #1 thing to do is think about how to speed up the drawing of the game. That might mean having fewer sprites on-screen, avoiding heavy particle effects, and so on. Remember your events and behaviors are part of the logic, which only takes 10% of the time. So even if you went to extreme pains and managed to get all your events and behaviors to run ten times faster overall, which is typically an impossible goal, you will just be reducing that 10% to 1%. The overall performance will just be a few percent better for hours and hours of work, and you could probably have got the same speed-up by reducing the rate of one of your particle effects.