Game Performance on Android sucks

0 favourites
From the Asset Store
Firebase: Analytics, Dynamic Links, Remote Config, Performance, Crashlytics on Android, iOS & Web Browser
  • Ashley, would you consider to allow us to switch the framerate mode in realtime?

    No, that's not a solution, it's just a hack which only raises further difficult problems, like: how do you know when to turn it on? There are thousands of different devices out there with different hardware and different software configurations. And if you get it wrong, you'll drain the device battery, which is a worse problem than you started with.

  • > Ashley, would you consider to allow us to switch the framerate mode in realtime?

    No, that's not a solution, it's just a hack which only raises further difficult problems, like: how do you know when to turn it on? There are thousands of different devices out there with different hardware and different software configurations. And if you get it wrong, you'll drain the device battery, which is a worse problem than you started with.

    In the devices with low performance caused by driver issue the fps are terrible making the game unplayable. Imagine someone who want to play your game, it download the game, then after some minutes you get 1 star rating complaining that more "advance" games run with no problem, so the problem must be the game, and in fact it is...Driver issue!

    As I said before, my friend with a good phone was unable to play because of the bad performance. I tried to change the framerate and the game at that point was playable and the fps were good.

    There could be several to know when you turn in:

    - In empty layout, if the fps are low change framerate mode after some seconds.

    - Allow the player to decide in the option if they want to boost the game as a lot of games do.

    Don't take my wrong, I'm not saying that the battery is not an issue, but the player must decide about it. Take for example Sky: the children of light. It completely drains out your battery, it allows you do decide the framerate and the performance. I played that game, I tried it. Even while you charge the phone the battery goes down. Is it a problem? yes. Do people still play it? Yes!

    A gamer knows already that by playing a game the battery will be suck it up. This hack will allow people with driver issue to play the game. Then, the decision is on the player if keep playing even if the battery goes down quickly, or stop playing. So, if there is a way to change the framerate mode in real time I don't understand why don't allow the developer to change it.

  • I think it's more likely that what you propose will make things worse, not better. Either the developers or the players will be likely to mis-configure the option, and then the situation is worse than it was to begin with.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I think it's more likely that what you propose will make things worse, not better. Either the developers or the players will be likely to mis-configure the option, and then the situation is worse than it was to begin with.

    We can already publish the game with unlimited frame rate mode. I read on the forum that even someone is using it to make sure that the app run smoother in all devices.

    The phone isn't going to explode. So I don't see all these problems. When you encounter a player with diver issues there is already a bad situation. You said that the Construct3 team can't do anything about it, but you could actually do something.

    As I said, I did a test. the game was running at 25/35fps in a device (totally unplayable). I tried to use the unlimited frame rate and the game was run much smoother (50/60). Still, I have to blacklist that device because I don't want to publish my app as unlimited frame rate since my game it runs smooth in most devices.

    So, if it is an easy implementation to do it you will make just the developers happy. I also think that it would be helpful if we want to debug stuff in real time.

  • If we had the opportunity to set unlimited at specific points (such as an intense scene with heavy use of particles, a boss etc) and then switch it off again in the more sedate places (menus, normal gameplay) then we'd get the best of both worlds and we (the developers) would be responsible for any issues that might arise.

    As far as I see it, there are plenty of other ways we can break our own games with the tools Construct already provides and I think it's better for us (the developers) to decide what happens in our own games rather than you guys.

    Maybe if the unlimited mode had never been put there in the first place I wouldn't be saying this, but it sure is tempting to use (if we could) in certain situations. If we cant' really use it I don't really understand why it's there at all.

  • We can already publish the game with unlimited frame rate mode. I read on the forum that even someone is using it to make sure that the app run smoother in all devices.

    A strong warning is shown on export if you try to do that, because you should never publish a game with that mode.

    What you are suggesting is an incredibly ugly hack that will not only prove very difficult to actually usefully apply, but could well make things even worse. It really is the wrong direction to go in. Just because you can doesn't mean you should.

  • Hey indy2005 did anything come of the bug report you posted on crbug.com? Seems like it got some input then just fizzled out? Was there any resolution?

  • Nope. And nothing will come of it. So I am now learning Blender and Unity...

  • Hi indy2005

    I faced same issue on 2018 with my main app on playstore and about 3K people suffered this issue.

    Send-me a message on my email or my whatsapp, i am glad to help you.

    luiscgforteshr@gmail.com

    +55 11940639243

  • LuisCGForte If you have any solution or advice, could you please share it here?

  • LuisCGForte we would love to hear the solution because we all suffer from the same problem

  • I had this problem twice, both of which required different solutions.

    In 2018 I had this problem and the solution was to compile/export the application on another computer with newly installed/updated windows.

    In 2020 the problem was repeated with another application and I solved it by deleting addons "even if the addon was not used in the project, it interfered with the app's performance!", Among other small adjustments such as collision, image size and even external JS libraries.

    Each case is a case to be analyzed in depth.

    Construct 3 is a powerful engine, 80 objects clearly shouldn't affect performance.

    Even old smartphones that do not meet the minimum requirements can run an C3 app sparingly, I see it happen daily via playstore in my apps/games.

    The best way to solve this problem is to debug and analyze the project and the computer of those who are developing it.

  • Thanks. I didn’t really buy a low code framework to have to do all this to be honest.

  • you wellcome

  • You can have only 15 - 20 instances of the same object and a game that will slow to a crawl if these instances overlap each other.

    And it may happen when exporting using runtime 3 and/or webworkers, then works fine if exported without webworkers and/or using reuntime 2.

    Don't ask me why , but it is true. My workaround was to change the collision detection method and it worked fine.

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