Lots of scenes? Slow navigating to the scene list? Speed it up with this simple trick!

Armelline

I'm working on a pretty big game right now with @manuelamisani (previews coming soon!). You may remember her game Zoe and the Magic Escape. There's a lot of scenes, more than I normally find myself dealing with. Pressing the "Home" button or bringing up the menu of scenes with the Scenes button started to take 10s of seconds. This was... annoying.

The game itself is 98mb so far. The project file is 450mb. Why? Screenshots. Screenshots everywhere. The screenshots ranged in size from 500k to 14mb. Every time I pressed that home button or brought up the layer list, it would have to load up all those enormous screen shots.

Backup your project file before attempting either of the below.

One solution is simple: Remove them. Just right click on the project file, do "Show package contents" and remove all the screen shots from the "Screenshots" folder. They're not actually needed, the only real use they have is to show the little preview when viewing the scene list.

A better solution is a little more work, but still super easy: Reduce their size! Right click on the project, show package contents, navigate to the screen shots folder and select all the screen shots. Double click to open them all in Preview (assuming you didn't remap pngs to another app). The dimensions of each one was 2560x1440 - but they're only being displayed as tiny little thumbnails. I selected them all, resized them all to 200x113, saved them all.

Now my project file has 6mb of screenshots instead of 350mb and the home screen and Scenes menu open near instantly.

Perhaps @adent42 could look at reducing the enormous resolution and footprint of these screenshots when he has a chance? A huge amount of how slow the GameSalad app feels in big projects is down to this.

bob loblaw

yep. what a pain in the arse those screen thumbnails are sometimes.

project size also gets jacked up the more you use unlocked actors, instead of instances/copies of actors. if you can avoid unlocking an actor, then avoid it. unfortunately gs doesn’t allow for fonts to scale size with camera zoom in/out (the actors that displays text will scale but the font stays the same size) so if you have a hud with “score:” and five digits that scales with zoom, you essentially have six new actors on each screen. that’s the way it seems anyway, unless someone knows something i don’t.

Armelline

Yup, every actor you unlock is essentially a whole new actor (which makes sense). Actors should only be unlocked if they're accessing camera attributes, and even then only one should be needed. Unlocking actors is one of the biggest mistakes newcomers to GS make, and was the death of my first game when I started with GS.

And you are correct, fonts don't scale with camera zoom, so you have to do the text/numbers using actors (one per digit for numbers). You have to have a very busy game indeed for it to have a real impact, though.

solnika

@Armelline and everyone else, What is your opinion on one actor to rule them all?

Still a way to go?

I find myself still doing things like advised years ago, putting all rules in one actor and all those tips.

One thing I never figure out is if one movable actor with all the rules is better then a few actors each have some rules.

Any thoughts ?

Armelline

It really depends on the circumstances. If you've got a mostly static scene, putting more into a single actor can be beneficial. If that actor is on the scene multiple times, or it's a very busy scene, it can be more efficient to only have the actors and code on scene that you need to be there. As a rule of thumb, though, I definitely aim for as few attributes, actors and tables as possible.

pinkio75

Hi, but is it better to have a few actors and in case disconnect them from the main ones?

if I remember correctly the best strategy was:

less actors, rules, attributes, tables, if everything is leaner everything runs better.

bob loblaw

depends on the project i guess.

Armelline

Not certain what you mean by "have a few actors and in case disconnect them from the main ones," @pinkio75 but as a rule of thumb less actors is good, fewer rules is good. I strongly favour attributes over tables unless tables just make more sense. Tables are one of the biggest causes of slow initial game loading. I never understood why they're so often recommended on here. Sometimes they're the best option but a lot of the time attributes will do just fine.

As @bob loblaw says, though - depends on the project.

pinkio75

Honestly I never use the tables maybe once or twice in all these years but sure as you say it depends on the project.