Optimizing Game Performance

by captaincomic (Updated on 2014-09-03)

Part of game development is creating logic that not only works but is optimized for fast, smooth gameplay that meets or exceeds the 60 frames per second mark. In Stencyl, there are many ways to improve your game's performance.



  • Avoid Too Many Collisions
  • Remove Print Statements
  • Limit use of "Make [actor] Always Active"
  • Limit number of on screen actors
  • Avoid expensive per-step calculations
  • Use Custom Drawing in moderation
  • Avoid drawing over the same spot many times


Avoid Too Many Collisions at Once

Stencyl uses Box2D for its physics engine, and the more Stencyl makes use of Box2D, the more calculations it's performing in a given step. Since collisions means the physics engine is working, more collisions means potential slowdown.


To avoid this, make sure the actors that are capable of colliding have something to do with the gameplay you're going for.

For example, unless you want bullets in your game to act like actual bullets, you can safely change their physics settings so they don't make more than basic use of Box2D when they collide with actors.

You can change the physics settings on the Physics > General page for an Actor.

Notice how we've set the collision style to "Cannot be pushed" and disabled both gravity and rotations.


Remove Print Statements Before Publishing

If you're using print statements in your game for debugging purposes, you need to remove these before publishing your game. Even when testing, having multiple print statements can really drag down your game's performance.

(Note: In Stencyl 3.0 and above, printing in published games is automatically suppressed. It's still useful to remove them while testing though!)


Limit How Often Actors Use Always Active / Simulate

Although it's often helpful for actors to function while off screen (which is what Always Active allows), consider when you really need to do this in your game and when you can avoid it. The more actors that are running all of their Behaviors off screen, the worse your game's performance will be.


Limit the Number of Actors on Screen

This can be tough when you want a game with a lot going on, but if you do need a lot of actors on screen, make sure you use actors you can recycle, i.e. those created with the Create Recycled Actor block.

The following article, Optimizing Actor Performance, explains ways to improve actor performance in detail.


Avoid Expensive Calculations Every Step

In the Always event block, you need to be careful about the types of calculations you choose to run here. The Always event block executes logic every step, so running calculations that take use a lot of processing power each step will slow down your game. Examples of calculations to avoid using in the Always event block include trigonometric calculations, random number generation, calculating the square root of a value, and those involving exponents.


Limit Use of Custom Drawing

The Drawing blocks under the Drawing category in Design Mode allow you to draw custom shapes on screen.

Using them takes up a lot of processing power, though, so take into consideration how many custom shapes you're drawing on screen at any given time. Consider pre-rendering your effects instead.


Don't Draw Multiple Things in the Same Place

When you draw anything on screen, avoid drawing things on top of one another. Doing this wastes processing power since you're drawing over the same spot multiple times.


Now it's your turn. Share your Tips.

What have you found, in your experiences, boosts performance of your games when you're in a bind? Use the comments area below to share your stories.

Disclaimer: All articles are geared towards Stencyl 3.0 and above. Use comments to provide feedback and point out issues with the article (typo, wrong info, etc.). If you're seeking help for your game, please ask a question on the forums. Thanks!


i foud out that when testing on android the scene transition "blur out/blur in" slows down the game dramatically,
but the "fade out/fade in" one works much much better

0 1 year, 1 month ago
VERY IMPORTANT when using physics: Turn off continous collision unless you REALLY REALLY need it. It shouldn't be checked as default and I'm sure that a lot of the "stencyl is slow"-chatter you hear comes from this simple fact.

Only if you discover that your fast moving actors are missing collisions or handling them improperly and you know what continous collisions are should you mess about with this option.

4 1 year, 6 months ago
For a letter puzzle game what is best (for android) ?
a) make a png image for each letter
b) make one png image and render the text on the blocks

0 2 years, 6 months ago
Does the number of regions in a scene drastically affect the games performance?
0 3 years, 3 months ago
Just wanted to note that if a collision does not need to be accurate you can get away with using hitTestObject(whatever) instead.
1 3 years, 9 months ago
What are some sample alternatives to using the Always block? I'm making a pong clone and I want to see if the player has scored by checking if the x-value of the ball is less than the x-value of the left-side player's paddle.
0 3 years, 10 months ago
Number 5 is right to warn against using expensive calculations every frame and to say that one way to avoid that is to put them in to conditional blocks as then they will not be done every frame
0 3 years, 11 months ago
The idea for 6 is to only use effects for short lived effects. If you want it to be longer you should just use GIMP to make the changes and put them as another animation.
0 3 years, 11 months ago
If the calculations or performed under an "If" statement block which is usually not true (ie. If mouse button is down), does the calculations under that "If" block get ran as well, or are they ignored/skipped until the "If" block's conditions become true?
1 4 years, 1 week ago
3-Limit How Often Actors Use Always Simulate. I do not understand what this means.. "always simulate".. is this a scripting function?
0 4 years, 1 month ago

Sign In to Comment