Title
GB Studio 3.1+ Tutorial.
Reducing slowdown and improving performance.
Last updated 3/2/2023.
Reducing slowdown and improving performance.
Last updated 3/2/2023.
Introduction
This tutorial was written for GB Studio 3.1.0 and is subject to change! A video version of this tutorial is available here:
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 nicely 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. They mostly involve reducing the number of scripts that are run every single frame. This tutorial will cover the following four strategies:
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 nicely 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. They mostly involve reducing the number of scripts that are run every single frame. This tutorial will cover the following four strategies:
- Replacing On Update scripts
- Improving On Update scripts
- Setting up the Enemy script
- Adding polish
Replacing On Update scripts
On Update scripts are the least performance friendly type of script, as they run every single frame, or 60 times a second at full speed.
That is a lot for the 30 year old Game Boy CPU to handle.
In my experience, On Update scripts are the main cause of slowdown in GB Studio games.
So, when appropriate, try to use On Hit or On Interact scripts that only run once, instead of On Update scripts that run 60 times a second.
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 another type of script.
A typical example of a wasteful On Update script is an On Update script that controls a health bar actor. In this example, the health bar actor’s graphics are updated every frame using its On Update script. You can see that the script itself is just a simple switch that changes the health bar’s graphics depending on the health variable, but when it runs 60 times a second in an On Update script, it can have a significant impact on performance. The health bar’s graphics do not need to be updated 60 times a second, rather they only need to be updated when the health variable changes.
Instead of using an On Update script, we can move the same behaviour to one of the On Hit scripts that is called just once when the player is hit.
In this example, when the player is hit, their health is reduced by one, and then the health bar’s graphics are updated to reflect this.
This means the script is only run once when it is required, and will have a negligible impact on performance.
You could include this script in either the player’s On Hit scripts, or the enemy’s On Hit scripts.
You would also need to add a script to the scene’s On Init script to set the health bar’s graphic once before the scene starts.
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 another type of script.
A typical example of a wasteful On Update script is an On Update script that controls a health bar actor. In this example, the health bar actor’s graphics are updated every frame using its On Update script. You can see that the script itself is just a simple switch that changes the health bar’s graphics depending on the health variable, but when it runs 60 times a second in an On Update script, it can have a significant impact on performance. The health bar’s graphics do not need to be updated 60 times a second, rather they only need to be updated when the health variable changes.
Instead of using an On Update script, we can move the same behaviour to one of the On Hit scripts that is called just once when the player is hit.
In this example, when the player is hit, their health is reduced by one, and then the health bar’s graphics are updated to reflect this.
This means the script is only run once when it is required, and will have a negligible impact on performance.
You could include this script in either the player’s On Hit scripts, or the enemy’s On Hit scripts.
You would also need to add a script to the scene’s On Init script to set the health bar’s graphic once before the scene starts.
Improving On Update scripts
Of course, there are many scenarios where using an On Update script is more appropriate or even necessary.
In these scenarios, we want to design the On Update script in the most performance friendly way possible, which is the focus of this next strategy.
To improve the performance of your On Update scripts, try the following:
- Add a 'Wait' event at the beginning or end of your On Update script.
For example, place a 0.1 second Wait event at the top or bottom of your On Update script, which is equivalent to an 0.6 frame Wait event.
This means the script will wait 0.1 seconds every time it runs, and only run 6 times a second, which is a lot more performance friendly than 60 times a second.
The tradeoff is accuracy, as the script may now take up to 0.1 seconds to update.
For example, a door that opens after defeating an enemy by using an On Update script may take up to 0.1 seconds to open after the enemy is defeated.
You may want to increase or decrease the length of Wait events to balance between performance and accuracy.
Even a single frame wait in an On Update script can significantly improve performance.
- Add more 'Wait' events throughout your On Update script. Where appropriate, you can add 'Wait' events throughout an On Update script to split up other events in the script between frames. Just make sure this doesn't impact the function of your On Update script.
- Minimise the amount of simultaneous 'Move' events.
'Move' events are performance intensive while the actor is moving, especially if collisions are in use.
Keeping the number of simultaneously moving actors on screen to a minimum will increase performance.
This can be achieved by placing 'Wait' events between actors’ movements, or just not having many actors to begin with.
You can also disable collisions where appropriate to minimize 'Move' events’ impact on performance, at the cost of actors no longer respecting background collision.
- Keep On Update scripts as short as possible. Try simplifying and optimizing On Update scripts wherever possible to avoid very long On Update scripts. 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.
Using intelligent game design
When initially designing your game, you should design your game with the knowledge that the Game Boy is not a powerful console, and that GB Studio games have less than optimal performance to begin with.
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 limited 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 realistic.
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 actors on the screen at once to optimise performance.
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, especially for your first few games, so try to adapt as you go.
Even a huge action adventure like Link’s Awakening doesn’t show more than 3 or 4 actors on the screen at once to optimise performance.
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, especially for your first few games, so try to adapt as you go.
Using CGB mode
Enable CGB mode to instantly improve your performance.
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, meaning On Update scripts can be much longer.
You can also have more actors on screen before slowdown becomes as noticeable.
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 CGB or GBA, not on DMG.
It should also apply in most emulators.
More resources
Now you can improve the performance of your GB Studio games.
The other tutorials on this site are designed with performance in mind.
Take a look at the general structure of the scripts in other tutorials.
It might help you to write your own efficient scripts.
If you have any queries about the tutorial contents (NOT general questions about GB Studio) contact me via my Twitter. Constructive feedback is appreciated.
If you have any queries about the tutorial contents (NOT general questions about GB Studio) contact me via my Twitter. Constructive feedback is appreciated.