Introduction.

One of the most common complaints from new GB Studio users is that their game is lagging or there is severe slowdown. Even for advanced users, getting your game to run well can be difficult. While the Game Boy isn’t a powerhouse, there are several strategies you can employ to increase your game’s performance and reduce slowdown. This guide aims to cover everything you need to know about improving performance in GB Studio games.

On Update scripts are the number one cause of lag.

On Update scripts are the main cause of slowdown in GB Studio games. They run every single frame, 60 times a second, which can be a lot for the old Game Boy to handle. If you have included On Update scripts in your scene, they are quite likely to be the cause of any slowdown you are experiencing. You can test whether they are causing slowdown by temporarily removing them and comparing performance. To reduce the slowdown caused by your On Update scripts, we can try a few different strategies.

Stop your On Update scripts from running every frame.

To stop your On Update scripts running every frame, you can add a ‘Wait’ event at the beginning or end of your On Update script. This means each time your On Update script runs, it will wait some amount of time before it runs again. Even waiting a single frame can significantly increase performance. When appropriate, you could also add multiple ‘Wait’ events throughout a script so that only part of the script is run at a time.

You can toggle whether 'Wait' events are measured in seconds or frames by clicking on the unit.

The tradeoff for adding ‘Wait’ events is that the accuracy of your scripts may decrease. For example, you might have a door actor that uses an On Update script to check a variable that tells it to be open or closed. If you put an 0.1 second ‘Wait’ event in said script, it may take up to 0.1 seconds for the door to register that the variable has changed. Short waits of less than half a second are usually not noticeable to players, but they may impact the logic of your game, so make sure to account for the loss in accuracy when adding ‘Wait’ events to On Update scripts.

Minimise the amount of ‘Move’ events in your On Update scripts.

‘Move’ events such as ‘Move To’ or ‘Move Relative’ are performance intensive and often cause slowdown when multiple actors are moving at once. If ‘Use Collisions’ is ticked in a ‘Move’ event, performance will be impacted even more. Untick this option to improve performance at the cost of actors no longer respecting background collision. Also keep the number of simultaneously moving actors on screen low by adding ‘Wait’ events between ‘Move’ events. It’s also a good idea to limit the amount of moving actors on screen to three or four.

A good example of an On Update script with 'Move' events.

Keep On Update scripts short and simple.

Try to avoid very long On Update scripts. The longer the script, the more code that has to be run every frame. If you must have a long On Update script, use ‘If’ events, ‘Switch’ events and other control flow events to ensure that only the necessary parts of the script are run on a single frame. Also use the ‘Stop On Update Script’ event to stop On Update scripts that are no longer needed.

Only use On Update scripts where necessary.

A common pitfall that new developers face is using On Update scripts where they aren’t required. The classic example is the health bar. Many new developers will use an On Update script to update the graphics for a health bar, running the script every single frame. In this example, an On Hit script is actually better than an On Update script, because health only changes when the player is hit, not every frame. An example of how to properly set up a health bar can be found here.

Does your On Update script need to run all the time, or just when a specific event occurs? If it doesn’t need to run every single frame, you may be able to replace it with an On Hit script or On Interact script.

Still lagging? Use intelligent game design.

When designing your game, you should always keep in mind that the Game Boy is not a powerful console, and that GB Studio games have generally worse performance than commercial Game Boy games. Come up with an idea that fits the Game Boy and GB Studio instead of trying to force an ambitious idea that doesn’t fit. This means designing the game with a limited number of actors and On Update scripts per scene. Look at Game Boy games published by Nintendo or other GB Studio games to get an idea of what may be achievable. There's a reason that the Game Boy library was overrun with puzzle games and RPGs, as the gameplay is simple, slow and performance friendly. Even a huge action adventure like Link’s Awakening doesn’t show more than 3 or 4 moving actors on the screen at once to optimise performance.

Some typical Game Boy games from this gallery of all original Game Boy games.

You may realise your game is overly ambitious part way through development. Don’t be afraid to scale back mid-development, whether that means cutting some features or restructuring altogether. It can be difficult to predict what GB Studio is capable of, so try to adapt as you go.

Double your performance with Color Mode.

The Game Boy Color has better hardware than the original Game Boy, and its CPU can run at twice the speed. In other words, it can basically do twice as much per frame before slowdown occurs. This means that On Update scripts can be much longer and there can be more actors on screen before slowdown occurs. To take advantage of this performance boost, tick the 'Enable Color Mode' box in your project settings. The performance boost will only apply when playing on Game Boy Color or Game Boy Advance, not on original Game Boy. It should also apply in emulators by default.

Guide by Shin. Last updated 7/12/2023.