This page is a draft for good practices to apply for optimizing GDevelop games.
This draft is WIP by @Bouh

Game optimization is an important concept of game development. Good optimization will allow the game to work faster, making it more fluid.

GDevelop 5 gives you total freedom in events. While this can be awesome, it can also be very costly if you don't have the reflex of writing optimized events, as the processor could get overloaded when running the game. This would cause lag in the game.

It is important to understand what events are and that all events are called once every second and in the order they were written.

For example: With a game at 60 frames per second (FPS), if you have a single event, without condition, and just one action, then this action should be executed 60 times in a second.

Optimization already in the engine

GDevelop has built in optimizations, like culling, the process of automatically hiding off-screen objects. That way less is rendered and the render gets faster.

This doesn't affect the person creating the game because it's handled in the background. It's totally transparent for everyone. For example, when a sprite is off screen all the animations are paused.

It is still important to hide or disable what you don't need. This is the key to optimization.

Optimizations you can perform

Trigger once

The Trigger once condition causes conditions preceding it in the same event to trigger only once every time they are met.

For example, if you want to create an object every time a click is done, this is what you should not do:

  • What is expected to happen: When the left mouse button is pressed, an object is created called MyObject.
  • What actually happens : As long as the mouse left button is pressed, MyObject instances are created.

This is problematic because when the mouse button is pressed, it is likely held down for longer than a single frame like 0.3 seconds. During this period of time the event is called multiple times, and the object is created more than once.

To fix that we can use the Trigger once condition:

Now, the condition will trigger only once while it is true. That means that the event will fire only once every time it's condition goes from unfulfilled to fulfilled. It resolves the problem above as the condition will fire only the first frame of the click, and will wait for the click to end before letting the click event fire again.

Decativate unused behaviors

Behaviors take performance, especially the Pathfinding and Physic Engine 2.0 behaviors. Remember to disable them when they are not needed.

Let's take as example the following situation: I want 100 enemies to move to a position close to them every 2 seconds, and to take into account the obstacles (to simulate guardian rounds with random paths).

This would be an intuitive but wrong way to do it: If you do this, all objects will move, including the ones that are off-screen.

Why calculate movement that the player won't see?

Instead, you can limit the movement to visible objects. This can be done the following way: disable the Pathfinding behavior of the objects not visible in the viewport, and also enable it when they are visible in the viewport.

Don't forget trigger onces to make sure the behavior gets disabled or enabled only when it's state changes from not visible to visible or the other way around

Delete unused objects

Let's take as example the following situation: I have a gun and I create one bullet object instance when I press the key to fire. This bullet has a force toward a direction. If the player shoots many bullets, their amount will increase on the scene and each one requires calculations of the force applied to them in the event loop. If you don't delete old bullet objects they will add up and take more and more performance causing lag to appear after playing for some time. The best solution is to delete the bullets that are off screen.

The behavior “Destroy when outside of the screen” does just that. Attach it to an object, and all bullets that go off-screen will be deleted.

  • The smaller the images the smaller gets the rendering time.
  • Images bigger than 2000px may not work well especially on mobile devices where they may not load at all.
  • Reduce the number of frames of a sprite animation as much as possible, get rid of frames too similar to the one before and next.
  • Use the profiler in GD5 for see which events are taking the most of the performance to try and optimize it
  • Reduce number of conditions as object selection is a heavy process.