Why my game always delay when change scene?

Weiyu

Hello everyone, I have a problem about change scene delay?

My game always delay when change scene?
Have anyone can give some advice for me? I have no idea why my game always happen?

Is my game too large? My game have 33MB.

Toque

Delay in creater or device? How long is the delay?

33MB is not that big.

Weiyu

@Toque said:
Delay in creater or device? How long is the delay?

33MB is not that big.

Thank you for answer

Both have same problem.
It always delay 5s~10s when I change the scene.

By the way, my game is quiz type, and every choices have 80 behaviors.
Do these behavior affects my game?

pHghost

The size of assets (images and sounds) affects this. It is the regular GameSalad loading time on scene switch. Unfortunately it can often be a long wait. One of the slight issues with GS. The only real sensible way around it is to build games in one scene, so you don't have to switch between scenes.

RedRobo

Quite old but still some gems here (take note of No1)
http://forums.gamesalad.com/discussion/46652/31-optimization-tips/p1

Socks

@strag said:
Quite old but still some gems here (take note of No1)
http://forums.gamesalad.com/discussion/46652/31-optimization-tips/p1

There is quite a lot on that list that is outdated and simply wrong.

birdboy

@Socks said:

@strag said:
Quite old but still some gems here (take note of No1)
http://forums.gamesalad.com/discussion/46652/31-optimization-tips/p1

There is quite a lot on that list that is outdated and simply wrong.

A lot of them are wrong? Which ones are you talking about exactly?

Socks

@Hoodloc said:
A lot of them are wrong? Which ones are you talking about exactly?

I'd question . . . 1, 2, 3, 4, 7, 8, 10, 11, 12, 13, 14, 18, 19, 20, 25 and 27.

The_Gamesalad_Guru

@strag said:
Quite old but still some gems here (take note of No1)
http://forums.gamesalad.com/discussion/46652/31-optimization-tips/p1

I agree with @socks most of that is bunk. I also don't recommend doing a single scene as that has it's own issues with clearing out ram (garbage collection issues).

You still didn't answer the first question. Delay on device or computer? If device what OS?

birdboy

@Socks A lot of them should be valid if GameSalad works like any other engine I know. Preload Art is a weird one because the "optimization" this list promises isn't further defined. It's hurtful to the runtime performance but it should shorten your loading times. But many other listed points should be correct if GameSalad hasn't changed stuff without announcing it.

Turning off moveable should turn off the physics engine for that actor. Doing that and using Interpolate instead of Move is much more performant (tested).

Using behaviors to animate instead of using multiple images is usually more performant (plus it shortens loading times and reduces ram usage).

Displaying images at a bigger or smaller size than their original one (or the mipmapped one for mobile) is usually less performant.

Saving images as png-8 makes makes them smaller. I think that's the kind of optimization @AcceleratedGames is talking about under point 13.

The rest is of similar kind. Using less global attributes, constraints and music helps performance (all of them have high impact on the performance or ram usage of a game). Don't see anything wrong with them.

Socks

@Hoodloc said:
Preload Art is a weird one because the "optimization" this list promises isn't further defined. It's hurtful to the runtime performance but it should shorten your loading times.

Agreed, my only real complaint about 1) is that it's conditional, there are of course situations where it's better to preload.

@Hoodloc said:
Turning off moveable should turn off the physics engine for that actor. Doing that and using Interpolate instead of Move is much more performant (tested).

I would question point 2) as there are situations where you'd want to uncheck 'moveable' that do - for instance - have a collide behaviour, for example a fixed wall that contains a collide behaviour. My real issue here is with blanket recommendations that are interpreted one way and end up as forum folklore.

@Hoodloc said:
Using behaviors to animate instead of using multiple images is usually more performant (plus it shortens loading times and reduces ram usage).

I have found the complete opposite to be true, and have tested this to the point of destruction (on multiple devices) and have always found animated image sequences to outperform their coded equivalent, of course there are all sorts of factors involved (number of rules, size of animated sequence ad so on) but I've always found in the situations I've come across (rotating, flashing, bouncing . . 'game' type scenarios) that using image sequences outperform rule based equivalents by a long way.

It's worth noting that if you dig through the resources of programmes like Logic Pro or C4D (and so on) you will find things like dials and meters and flashing buttons (and so on) are done as animated image sequences, usually in the forum of a single image strip, for example a dial that you might rotate in Logic Pro will be stored as a long strip of images, one for every degree of rotation.

@Hoodloc said:
Displaying images at a bigger or smaller size than their original one (or the mipmapped one for mobile) is usually less performant.

Agreed, I don't think this was in his list ?

@Hoodloc said:
Saving images as png-8 makes makes them smaller. I think that's the kind of optimization @AcceleratedGames is talking about under point 13.

They will be held in a 24/32bit colour space when in RAM, so although they might be smaller on disk* (*but not necessarily) they will offer no improvements in game performance.

@Hoodloc said:
The rest is of similar kind. Using less global attributes, constraints and music helps performance (all of them have high impact on the performance or ram usage of a game). Don't see anything wrong with them.

Music has no effect on performance, music is handled by dedicated hardware on the device, it's streamed, it has no impact on RAM usage - (this is why we make a distinction between 'sound' and 'music').

The rest of the list is full of some questionable ideas . . . 'all images should be 72dpi' . . not a terrible recommendation, but the ppi of an image has no effect on either the image itself or the game performance, what matters is the absolute pixel count, a 512x512px image at 8600ppi and a 512x512px image at 12ppi are identical, neither will have a performance advantage . . . . 'Don't use the color changer within GameSalad unless necessary" . . what !? Lol, that one's just weird . . . 'All images should be divisible by 4' . . . although like the 'all images should be 72dpi' idea it's not in itself a bad recommendation, it's not actually going to impact performance in anyway, and there are plenty of (I would argue more) situations where the whole point of the divisible-by-4 recommendation is entirely irrelevant, the goal here is to align image pixels to screen pixels 1:1, but if something is moving, spinning, growing in size, shrinking, parallaxing, bouncing, exploding . . . etc . . (basically 95% of all games) then the divisible-by-4 rule is irrelevant . . . . etc etc

RedRobo

Sorry guys, posted in a hurry, should have added a disclaimer that not all are necessarily valid or tested.

The main thing that made me think of it was I had the same issues with scene loading time in a previous game and the list helped me. With regard to point No1 unchecking preload art and dynamically loading some actors during gameplay solved the problem for me.

Obviously we are all making hugely varied games and apps so it will not be viable in all cases.

I'm off to repeatedly flog myself to within an inch of my life with my Beginners Guide to GameSalad whilst reciting " I vow to be a better and more thoughtful person for the good of all involved now and forever and ever"...

Socks

@strag said:
I'm off to repeatedly flog myself to within an inch of my life with my Beginners Guide to GameSalad whilst reciting " I vow to be a better and more thoughtful person for the good of all involved now and forever and ever"...

Video or it didn't happen.

RedRobo

It continued well into the night...!

The_Gamesalad_Guru

As @socks pointed out many of us, including myself have tested the validity of many of those things. Things like timers et.. were fixed many versions ago. Now that we have the can sleep option you can keep things moveable for collisions and such. They will be out of the physics until interacted with and then after sometime go back to sleep. Much has changed with the engine as to scan and such during the last version produced by codewizard. I break most all of those performance no, no's all the time. Performance I content is good slim proper code. I have rarely experenced the kind of lag, delays others see.

viking

@The_Gamesalad_Guru I downloaded Puck It from the AppStore, but it crashes out on my iPhone 7+. Are you going to update it? I would love to check it out.

As for scene switching times and loading times in general I was able to gather the following after testing on GS 1.25.73 an iPad 3:

1. Just loading the engine with two scenes with just one actor in the first scene changing to scene 2 (needed because of the weird splash screen bug) with one display text actor in scene 2 and no art takes 7.5 seconds from tap of the icon and until the second scene actor appears.
2. Adding about 2Mb of art assets to the second scene, but not putting them into any actors placed in the scene also took 7.5 seconds.
3. Added several actors without any logic to scene 2 and added art to the actors took 7.7 seconds to load. Not a big increase.
4. Then I added 20 tables with no data in them and this also takes 7.7 seconds.
5. Added 150 rows and 30 columns of dense data in all 20 tables to see if tables and table data slows down loading times. Same result as with empty tables. 7.7 seconds.
6. Added about 500 actions in one actor in scene 2 and the loading time increased to 9.3 seconds. This is a huge difference in loading time compared to adding tables and art.
7. I took the 500 actions and grouped them together. Then I copied and pasted that group in the actor five times to multiply the amount of code in the actor by 5. That increased the loading times from 9.3 to 9.7 seconds.
8. Then I turned off pre-load art on all actors in scene 2 and the loading time was reduced to 8.8 seconds.
9. Then, I turned off all logic in all actors and loading times came back down to 7.7 seconds, which confirms that logic in the actors are indeed by far the most impactful on load times.
10. To test the loading time impact on using tables, not just loading them, I added about 300 change table value instructions in one actor, but it did not change the loading times. So anything you can do using tables might help you in terms of loading times.
11. Finally, I tested using an actor with a minimal amount of logic in it and placed it in the scene, but then had that simple actor spawn a five times 500 action heavy actor and the loading times went back up to 9.7 seconds. So any actor that can be spawned in the scene is also counted towards your loading time as if it was already placed in the scene.

I hope this helps in better understanding how GS loads data into memory when it starts up your project.

Hopscotch

@viking said:
...

My experience as well.

This is the unfortunate thing with GS. It is not the actual "loading" that takes long, but the time GS takes to initially step through all of your code recursively to sniff out possible images and SFXs it might need to load (same between scenes).

Would be cool if this was faster, alternatively a flag to prevent this. There are other ways to make sure an image or sound is loaded when needed, leave it up to the developer. Hmm, an expert mode flag would be nice!

Socks

@viking said:
@The_Gamesalad_Guru I downloaded Puck It from the AppStore, but it crashes out on my iPhone 7+. Are you going to update it? I would love to check it out.

As for scene switching times and loading times in general I was able to gather the following after testing on GS 1.25.73 an iPad 3:

1. Just loading the engine with two scenes with just one actor in the first scene changing to scene 2 (needed because of the weird splash screen bug) with one display text actor in scene 2 and no art takes 7.5 seconds from tap of the icon and until the second scene actor appears.
2. Adding about 2Mb of art assets to the second scene, but not putting them into any actors placed in the scene also took 7.5 seconds.
3. Added several actors without any logic to scene 2 and added art to the actors took 7.7 seconds to load. Not a big increase.
4. Then I added 20 tables with no data in them and this also takes 7.7 seconds.
5. Added 150 rows and 30 columns of dense data in all 20 tables to see if tables and table data slows down loading times. Same result as with empty tables. 7.7 seconds.
6. Added about 500 actions in one actor in scene 2 and the loading time increased to 9.3 seconds. This is a huge difference in loading time compared to adding tables and art.
7. I took the 500 actions and grouped them together. Then I copied and pasted that group in the actor five times to multiply the amount of code in the actor by 5. That increased the loading times from 9.3 to 9.7 seconds.
8. Then I turned off pre-load art on all actors in scene 2 and the loading time was reduced to 8.8 seconds.
9. Then, I turned off all logic in all actors and loading times came back down to 7.7 seconds, which confirms that logic in the actors are indeed by far the most impactful on load times.
10. To test the loading time impact on using tables, not just loading them, I added about 300 change table value instructions in one actor, but it did not change the loading times. So anything you can do using tables might help you in terms of loading times.
11. Finally, I tested using an actor with a minimal amount of logic in it and placed it in the scene, but then had that simple actor spawn a five times 500 action heavy actor and the loading times went back up to 9.7 seconds. So any actor that can be spawned in the scene is also counted towards your loading time as if it was already placed in the scene.

I hope this helps in better understanding how GS loads data into memory when it starts up your project.

Excellent, really useful info.

"which confirms that logic in the actors are indeed by far the most impactful on load times"

This backs up @The_Gamesalad_Guru's often repeated mantra 'slim efficient code' is the way to go.

viking

@Socks Thanks I agree. So I would like to measure Puck It against my games and use it as the gold standard. But the game must be re-published first.

Toque

Really good to know.

The_Gamesalad_Guru

@viking said:
@Socks Thanks I agree. So I would like to measure Puck It against my games and use it as the gold standard. But the game must be re-published first.

If you want to see me build slim efficient code watch my "custom collision shape animations" It a classic example of complex code designed in a lean mean manner. I coded puck it years ago. Work has been crazy and at some point I want to republish it and do another game. I may take on the challenge of doing a "street fighter" type game using my custom collision shape animation technique. The tricky part will be the computer opponent!

The_Gamesalad_Guru

@Socks said:

@viking said:
@The_Gamesalad_Guru I downloaded Puck It from the AppStore, but it crashes out on my iPhone 7+. Are you going to update it? I would love to check it out.

As for scene switching times and loading times in general I was able to gather the following after testing on GS 1.25.73 an iPad 3:

1. Just loading the engine with two scenes with just one actor in the first scene changing to scene 2 (needed because of the weird splash screen bug) with one display text actor in scene 2 and no art takes 7.5 seconds from tap of the icon and until the second scene actor appears.
2. Adding about 2Mb of art assets to the second scene, but not putting them into any actors placed in the scene also took 7.5 seconds.
3. Added several actors without any logic to scene 2 and added art to the actors took 7.7 seconds to load. Not a big increase.
4. Then I added 20 tables with no data in them and this also takes 7.7 seconds.
5. Added 150 rows and 30 columns of dense data in all 20 tables to see if tables and table data slows down loading times. Same result as with empty tables. 7.7 seconds.
6. Added about 500 actions in one actor in scene 2 and the loading time increased to 9.3 seconds. This is a huge difference in loading time compared to adding tables and art.
7. I took the 500 actions and grouped them together. Then I copied and pasted that group in the actor five times to multiply the amount of code in the actor by 5. That increased the loading times from 9.3 to 9.7 seconds.
8. Then I turned off pre-load art on all actors in scene 2 and the loading time was reduced to 8.8 seconds.
9. Then, I turned off all logic in all actors and loading times came back down to 7.7 seconds, which confirms that logic in the actors are indeed by far the most impactful on load times.
10. To test the loading time impact on using tables, not just loading them, I added about 300 change table value instructions in one actor, but it did not change the loading times. So anything you can do using tables might help you in terms of loading times.
11. Finally, I tested using an actor with a minimal amount of logic in it and placed it in the scene, but then had that simple actor spawn a five times 500 action heavy actor and the loading times went back up to 9.7 seconds. So any actor that can be spawned in the scene is also counted towards your loading time as if it was already placed in the scene.

I hope this helps in better understanding how GS loads data into memory when it starts up your project.

Excellent, really useful info.

"which confirms that logic in the actors are indeed by far the most impactful on load times"

This backs up @The_Gamesalad_Guru's often repeated mantra 'slim efficient code' is the way to go.

As I say, in my client projects and my own prototype projects I never see lag. If I did see lag, I would find the offending code branch and redesign it. What I find is most users don't design their code, they just go with their first idea of how to code it. When I design a logic tree, I might figure out ten ways to do it before I find the most efficent way. I do lots of prototyping of logic before I implement it.