Mobile Game Best Practices?

GDevelop general
1

Hello,

Just wondering if the community could maybe provide some best practices with regards to mobile game development?

For example, does GDevelop automatically pause the game when a player puts it in the background (e.g. hits the home button, or uses the ‘app list’ to switch to a different app, or a phone call comes in, or whatever), or do we need to use some event in the scene event loop to detect that we have gone into the background, and automatically pause the game?

Mobile phones (well, Android - I’m not familiar with how iPhone works) will also at some point automatically close background apps if the user doesn’t use them for some amount of time, won’t they? Can we provide a shutdown handler to automatically save the game state, so that when you resume the game it’s right back where it was? Or does GDevelop automatically save the state?

Is there any best practices around power management (to make sure your game doesn’t kill the battery too fast)? I presume mainly, the only thing to worry about there is to just not do too much processing in the main game loop? Maybe don’t make network requests too often (e.g every frame)?

Most 2D games don’t do that much processing anyhow, that they would take up a lot of battery, but I think that is probably the main concern with regards to power?

Is there a way to rate-limit GDevelop games? Like, I’m thinking that even though hardware might be able to render the game at 120fps, it might make sense to configure GDevelop to rate-limit the game to like 24 or 30 fps, if your game doesn’t really require high frame rates, just to save power?

2

I’ll be looking forward to see answers to this topic, too.

In my case, the use of TimeDelta() has shown a HUGE performance difference in mobile games.

3

Sorry guys, zero experience with mobiles, but AFAIK GD does nothing special regardless if it’s mobile or not:

  • There was a “window focus” condition before, for native, but it doesn’t exist for the web platform. In other words, if GD doesn’t handle focus lost automatically you can’t do it :confused:
    I should check this because IIRC html5 games get paused when you switch tabs, maybe it’s the same for phones. Will tell you later.

  • There is no FPS cap/max FPS, the project has this property if you open a .json project file, but is never used, the time manager only take the minimum fps into account: https://github.com/4ian/GDevelop/blob/master/GDJS/Runtime/timemanager.js#L27

  • You can’t do much for the battery, nor GD does, it will try to run at 60 FPS, and in each frame will update all that must be updated (object, timers, behaviors, forces, etc.), it does things like avoid updating sprite animations if the object is not visible and such, but nothing special for mobiles.
    All you can do is improve your events to run only once things that must be run only once, for example, to display a score variable in a text object, instead of updating the text every frame, you could update the text only in the events that modify the score variable.

The framerate limit could be added, in case somebody wants to give it a try, the maxFps data should be read and stored in the game around here: https://github.com/4ian/GDevelop/blob/master/GDJS/Runtime/runtimegame.js#L29
Add a getter like the one for minFps: https://github.com/4ian/GDevelop/blob/master/GDJS/Runtime/runtimegame.js#L241
Pass it to the time manager here: https://github.com/4ian/GDevelop/blob/master/GDJS/Runtime/runtimescene.js#L225
And add the maximum fps argument in the time manager: https://github.com/4ian/GDevelop/blob/master/GDJS/Runtime/timemanager.js#L27

Then in the time manager update function is where the black magic must be done, not sure, but I guess it should be something like:

update(elapsed, minFPS, maxFPS): totalElapsedTime += min(elapsed, 1/minFPS) if totalElapsedTime >= 1/maxFPS: elapsedTime = totalElapsedTime * timeScale totalElapsedTime = 0 updateAndRender(elapsedTime)

4

Thanks for those additional thoughts.

That makes sense that, since the games are HTML5 scripts, at heart, that most of the lifecycle management is essentially handled by the browser. I would think it would be the case that if you go out of the browser, or switch to another browser window, it would probably pause the game/script, and the browser would probably, for at least a little while, maintain the state of the script to resume it when the player returns to it.

The one thing I’m concerned about is that it sounds like that might leave us with no way to automatically save the game state if the player leaves, and doesn’t come back for awhile - at some point, I suspect the browser will terminate and garbage collect the entire game engine if it’s left inactive in the background for too long.

When I get a chance, I will definitely do some testing around this.