Question For Very Experienced Mobile developers.

  • Nesteris,

    Actually I wouldn't worry at all about most Every Tick events. The biggest source of slowdown on mobile is related to graphics, not logic. Unless you've got some hardcore physics calculations happening, forget optimization and just make sure your code is organized and pleasing to the eye. Setting A equal to B every tick has practically zero impact on performance. Ashley has addressed this on his blog. If you haven't already, read it and feel relieved.

    https://www.scirra.com/blog/83/optimisa ... -your-time

    The best advice is to periodically export the game and check its performance on mobile. That way, if you made a change that breaks performance, you can re-evaluate your approach.

    <img src="{SMILIES_PATH}/icon_eek.gif" alt=":shock:" title="Shocked">

    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.

  • +1 i could not think of what to reply with here but that post puts it pretty perfectly.

  • 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.

  • I'm a computer engineer with a specialty in analysis of algorithms

    In my experience, the optimization of a mobile game is a critical point because not everyone will have the last device

    Take a look at Ashley's topics about optimization, they are an excelent summary

    Just keep in mind that there is always room for better performance

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • To quote Ashley from the "Optimisation: don't waste your time" blog post:

    [quote:d9gjptbb]

    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.

    If you want to use that quote, you have to get specifics, define a "fairly complex" game.

    Any mobile gamedev who has used C2 on a large project knows its limitations: JS suffers a performance penalty especially on mobiles. It's also single threaded which is not good for mobile CPUs which are often made up of 4 weaker cores (imagine only ever using up to 25% of a mobile device's capability!).

    Optimizations is key for mobile devs. Ignore it at your peril, then come back and make a post about why "C2 sucks for mobiles" or "C2 performance on mobiles blows donkey"... like the many threads we have on these forums on a daily basis.

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