GameSalad

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

★★ 31 Optimization Tips ★★

AcceleratedGamesAcceleratedGames Posts: 201Member
edited April 2013 in Community Tutorials
Hello GameSalad Community,
One thing that I know we all care about is performance. Even with the new LUA-Free engine coming soon, we would all still like our games to be fast now. I have made a list of 31 optimization tips to use in your games that I have collected after searching through the forums, coming up with some myself, and exploring GameSalad help websites. I did this so you only needed to go to one thread instead of taking the amount of time it took me to find it all.
Here it is.

1. Uncheck "Preload Art" on as many actors as you can.

2. Uncheck "Movable" for every actor that doesn't have the "Accelerate", "Change Velocity", "Collide", "Move", "Move to", or any of the rotate behaviors.

3. Use the "Interpolate" behavior instead of the "Move", "Move to", and "Change Size" behaviors whenever possible.

4. Use the "Rotate" behavior instead of animations.

5. Turn every attribute under the physics tab in the actor editor to 0 on actors who do not need it.

6. If the actor is not going to be seen, change their "Visible" attribute to false.

7. Instead of using the "Change Image" behavior, use "Change Attribute" and change the self.Image to the desired image's name.

8. Images should be the same size as the actor using them and double the size if you are using Resolution Independence.

9. Change any image that is about 10 pixels more than 8, 16, 32, 64, 128, 256, 512, or 1024 to which ever of these numbers are closest.

10. If an image file is large or is a background, have the actor that uses the image use the suggestion in number 7 instead of having the actor start initially with the image.

11. All images should be 72dpi.

12. Save all images as PNG-24 or PNG-8

13. Save all images as PNG-8 unless they have any transparent or translucent object in them.

14. Don't use the color changer within GameSalad unless necessary.

15. All images should be divisible by 4.

16. Make sure your image creator is set to 8-bits/channel.

17. Don't use the "Display Text" behavior wherever possible.

18. Try not to use so many global attributes and use tables wherever possible.

19. Try not to use timers. See http://forums.gamesalad.com/discussion/44707/timers-are-for-chumps-gs-optimization-tips

20. Limit constrains and if you do need to use it, make sure that they are on the top of your code.

21. Make your own pause instead of using the behavior. See http://gshelper.com/stop-motion-on-custom-pause-gamesalad-tutorial/

22. If an actor is not being used again in the same scene, destroy it.

23. If you have a game that goes on forever like Jetpack Joyride, Temple Run, or Jay & Silent Bob in Too Fat to Fly, make sure you either move or destroy actors that pass you by using these rules:

Landscape gameplay: If attribute game.MainCharacterPositionX > self.Position.X + (game.Screen.Size.Width/2)+(self.Size.Width/2), then destroy or move.
Portrait gameplay: If attribute game.MainCharacterPositionY > self.Position.Y + (game.Screen.Size.Hight/2)+(self.Size.Hight/2), then destroy or move.

24. You do not have to recycle actors that would be destroyed in the first place, like bullets.

25. Use music at your own risk because it will decrease performance.

26. Delete all unused rules, groups, behaviors, actors, attributes, images, and sounds.

27. Don't save more than 3 attributes at once.

28. Don't update all Game Center Achievements/Leaderboards at once unless their is no movement in the scene at that time.

29. Make an initial scene that looks like your splash screen to load attributes and log in to Game Center

30. If you can, unlock actors to constrain to the actor directly. See: http://gshelper.com/gamesalad-performance-tip-1-2/

31. Test your game using Instruments to see the memory, cpu, frame rate, leaks, battery usage, and a lot more.

After using these all in my game, it runs at more than 60 fps on the original iPad constantly.
«1

Comments

  • ChimoruChimoru Posts: 137Member, PRO
    This is an awesome compilation of tips, thanks a lot for taking the time to post these!
  • KiwiLeeKiwiLee Posts: 181Member
    Brilliant. Does anyone know if using Instruments is useful for us whilst the LUA engine is in place. Anyone got some tips of how to use it? Perhaps this could be a video @TShirtbooth :-)
  • POLYGAMePOLYGAMe Posts: 3,470Member
    I thought you should recycle bullets etc rather than spawning and destroying, as GS doesn't actually delete objects properly? Or has this been fixed now?
  • AcceleratedGamesAcceleratedGames Posts: 201Member
    edited July 2012
    To my knowledge, they have fixed that problem, if it ever existed. I tried both methods and the average of the memory used to spawn was LESS than it was to recycle the bullets.
  • POLYGAMePOLYGAMe Posts: 3,470Member
    Ah, okay. I shall recompile then! That issue DEFINITELY existed... Max Vector crashed eventually because of the build up of bullets that weren't being deleted properly. I had to cut back the game massively to make it work. I think I'll give it a go of recompiling the original, much better version if that issue is all fixed up. This is good news :)
  • AcceleratedGamesAcceleratedGames Posts: 201Member
    edited July 2012
    KiwiLee said:

    Brilliant. Does anyone know if using Instruments is useful for us whilst the LUA engine is in place. Anyone got some tips of how to use it? Perhaps this could be a video @TShirtbooth :-)

    Instruments works with everything on a Mac, iPhone, iPod, and iPad.
    To use Instruments, make an AdHoc version of your game, put it on your device, open the game, then...

    https://www.dropbox.com/s/gqrel07c876kai5/Instruments.mov

  • creativeappscreativeapps Posts: 1,771Member
    @AcceleratedGames Thank you so much for the tip. Its really helpful for us.
  • DanielDoeDanielDoe Posts: 307Member
    Does pt.14 really matters? I use build-in color tool to almost every actor but did't notice any change in performance. Turning all movable to 0 also didn't change to much. The biggest diffirence I can see is by reducing image size and reducing spawning objects.
  • AcceleratedGamesAcceleratedGames Posts: 201Member
    edited July 2012

    Does pt.14 really matters? I use build-in color tool to almost every actor but did't notice any change in performance. Turning all movable to 0 also didn't change to much. The biggest diffirence I can see is by reducing image size and reducing spawning objects.

    Tip number 14 applies specifically for HTML5 games. Also, by changing all physics to 0, it makes actors move faster in general and does make a difference when you have many objects on the scene. This tip actually made the biggest difference in my game.
  • DanielDoeDanielDoe Posts: 307Member
    I'll try with physics... thanks for that.
  • ADTaylorADTaylor Posts: 10Member
    Can you explain the use of point 9 to me? I don't see how changing the size of the graphics is going to make a difference?
  • AcceleratedGamesAcceleratedGames Posts: 201Member
    ADTaylor said:

    Can you explain the use of point 9 to me? I don't see how changing the size of the graphics is going to make a difference?


  • SlickZeroSlickZero Houston, TexasPosts: 2,870Member, Sous Chef
    ADTaylor said:

    Can you explain the use of point 9 to me? I don't see how changing the size of the graphics is going to make a difference?

    Using odd dimensions will give you a blurry image on the device. Those numbers are the most common for a perfectly clear image, and are the benchmark for memory used for an image, but it doesn't HAVE to be one of those. For example, if your image is 58x112, it will use up memory for an image that is 64x128, but will still be a clear image. If you go over those benchmarked numbers listed even by 1 pixel, the memory usage will jump to the next size for the image. So if you had an image that was 66x66, it would use the memory required for an image that is 128x128 instead of 64x64

    As long as your image is divisible by 2 or 4 and still remains an even number after dividing it, it should be fine, but keep in mind the memory usage for image sizes, you can wind up wasting a lot of memory on images that are oversized just by a few pixels.

    I have no friends. I'm a loser that makes video games all day. Will you be my friend?

  • JDuaneJJDuaneJ San Francisco Posts: 300Member
  • StormtrixStormtrix Posts: 256Member
    Pt. 17 on display text.. i'm working on a new educational app that is using tables for my lessons and filling it with text then using display text to show it like reading a book. Didn't think this would be much of a problem??? i'm only using 1 or 2 display texts for a scene/page and just when someone hits the next page it just displays the next column in the table. see any problems with that?
    thx
  • JDuaneJJDuaneJ San Francisco Posts: 300Member
    Soooo using Change Image is bad??? Why is something native to this program so bad? When would you use it then?

    So change self image is faster? I have about 60 actors all changing images on touch.
  • DoguzDoguz Posts: 500Member
    Umm. what is Instruments? Never heard that before.
  • JDuaneJJDuaneJ San Francisco Posts: 300Member
    Does setting the actor's visibility to false actually have an effect on performance? Are these gains worth the extra code?
  • nikkonnikkon Posts: 111Member, PRO
    JDuaneJ said:

    So how does one use Instruments with gamesalad?

    install ad hoc build to iphone/ipad > plug iphone/ipad into mac with usb cable > load xcode on mac > go to menu xcode > open developer tools > instruments
  • SlickZeroSlickZero Houston, TexasPosts: 2,870Member, Sous Chef
    @JDuaneJ - You can't use Instruments with GameSalad.

    @Stormtrix - You shouldn't have any problems with that.

    @Dougz - Instruments is a program that is used with Xcode.

    @JDuaneJ - Using Change Image is not bad, but using change self.image seems to work better, as far as performance is concerned. I haven't noticed a difference personally, but lots of people swear by it.

    And any little bit you can do to improve performance is well worth the time to implement the technique for a quicker loading/responding game. It all adds up in the end.

    I have no friends. I'm a loser that makes video games all day. Will you be my friend?

  • JDuaneJJDuaneJ San Francisco Posts: 300Member
    @nikkon thanks!!

    @SlickZero sounds good. I definitely want to make stuff for the long haul so any bit does help. you're right.

    I can't see to get the visibility to function correctly with a change attribute. I can get it to work when I physically change the boolean, but not with the change attrib.
  • JDuaneJJDuaneJ San Francisco Posts: 300Member
    This list pretty much saved my app! Thanks so much for the collected wisdom! I was afraid I was going to have to not support 1st gen ipads, but now it seem like performance is tolerable on the 1st gens. (few hiccups still tho) :D
  • debugdesigndebugdesign Posts: 886Member
    This is a great list... Thanks for sharing!

    I think I will have to pinch it for my blog so I can always find it!
  • SocksSocks London, UK.Posts: 12,822Member
    Great post, some great tips.

    : )
  • FirstDanFirstDan Posts: 208Member
    24. You do not have to recycle actors that would be destroyed in the first place, like bullets.

    what does the above mean?#

    does this mean, i shouldn't recycle
  • SocksSocks London, UK.Posts: 12,822Member
    @FirstDan

    Yeah, I'm a little confused by that one too, since time began people have always advised you to recycle so you are not spawning hundreds of actors . . . . so it's weird to see 24 ?
  • AcceleratedGamesAcceleratedGames Posts: 201Member
    edited December 2012
    Recycling used to be necessary when destroying actors didn't actually destroy the actor. Since that bug was fixed, recycling just adds unwanted code and slows the game down even more than destroying the individual actor.
  • SocksSocks London, UK.Posts: 12,822Member
    edited December 2012
    @AcceleratedGames

    Cheers for the explanation, I wasn't aware of the destroy bug.
  • SocksSocks London, UK.Posts: 12,822Member
    7. Instead of using the "Change Image" behavior, use "Change Attribute" and change the self.Image to the desired image's name.
    SlickZero said:

    Using Change Image is not bad, but using change self.image seems to work better, as far as performance is concerned. I haven't noticed a difference personally, but lots of people swear by it.

    Anyone got anything to back this up with (an example project maybe) ? I've tried both 'change image' and 'change attribute / self.Image' and can't see any difference.
  • PixelMetalPixelMetal Posts: 283Member
    edited January 2013
    Socks said:

    7. Instead of using the "Change Image" behavior, use "Change Attribute" and change the self.Image to the desired image's name.

    SlickZero said:

    Using Change Image is not bad, but using change self.image seems to work better, as far as performance is concerned. I haven't noticed a difference personally, but lots of people swear by it.

    Anyone got anything to back this up with (an example project maybe) ? I've tried both 'change image' and 'change attribute / self.Image' and can't see any difference.
    Try constrain image instead of change image. Change image doesn't seem to work reliably for swapping an image. Also, you don't need the image extension in the name, so if the graphic is called "image.png" just put "image" (minus quotes).
Sign In or Register to comment.