Managing Scene Load Times.

jamesmunro2

I am looking for ways to manage the time it takes GS to load a scene.

I assume that the load times in the viewer on my ipod are the same as the completed game, or is it pre-compiling on the fly?
I assume GS only loads the resources needed for each scene.
I am also assuming the number of resources loaded increases the load time.

So my question:

If I have 10 scenes in my app...

And the 10th scene loads slowly. There are resources needed for that scene are not used in earlier scenes...

Can i Preload resources (create a rule to play music that never gets met) in earlier scenes to reduce the wait time on the 10th scene (and slightly increasing the time between the first 9 scenes to bring in the additional resources early?)

Is there another way that scene load times can be managed and manipulated?

simo103

would also be interested to know the answer to this one. Until/if it gets a response I thought I would throw in a technique I am trying that seems to help.

My scenes are 960 tall (in portrait) and I have two game levels and a transition level, each the regular 320 tall and move the camera between each. Once the two levels are complete it shows the third panel which has a success message and some tips on actions needed in the next level. I also have 'Auto loading next level' showing. When this last panel comes into camera view I trigger the next scene so this panel is visible during the delay.

jamesmunro2

Thanks for your reply. Those are some good ideas. I've bounced similar ideas around, and am planning on using this technique for my next game so I can plan better... which was really the reason for my question.

I am kind of surprised that I didn't get more of a response. I guess load times for scenes are kind of the"elephant" in the room. We all know its there, but we just ignore it.

I would really like more ideas and knowledge so I can manage these load times better. I'm sure I'm not the first person to try to optimize in this way.

simo103

jamesmunro2 said:
I would really like more ideas and knowledge so I can manage these load times better. I'm sure I'm not the first person to try to optimize in this way.

Agreed .. I guess this really needs a GS staffer to weigh-in on based on their knowledge under the hood. The pre-caching of objects is a often utilized technique in websites and similar techniques are used in database management so I think there could be something here, even perhaps knowing the order certain things are loaded and/or if there is a way to effect that.

entersimon

Well, I don't have an answer to your question, but I have been working very hard on optimization for the past week, and through some really long test procedures and lots of reading on the forums I'd like to share what I've found.

Small amounts of anything seem to be ok without too much drawback to load times and resource usage. This includes spawning, timers, constrain, and change attributes (each of these being on the big no no list but sometimes unavoidable).

What I've found is that if you have relatively few actors (30 or less) with optimized graphics and audio, "creating the scene" after the initial load works nicely. That is to say you need an app that can utilize this. If everything you're going to be using in the game is shown on the screen right off the bat, you're probably stuck, but if you have off camera actors, there is some hope.

I stagger spawning by 1 second each instance of an actor. If these actors don't have to go through a list of rules that change their attributes (i.e. if self.x = 15 change the color to whatever, if self.x = 16 change to a different color) then there is no drop in frame rate and ram usage increments up normally. What I've found, and am desperately trying to work around, is if you do have a (large) list of rules that change attributes based on an attribute, each spawn EATS RAM like it's been trapped in the desert for a week. An example of this is a .1 meg image used on an actor will spawn and add .1 RAM usage when this is done. If this actor goes through a large list of rules, then for some unexplained reason, the RAM usage for each actor jumps to about 1 meg each. This does affect frame rate and causes the game to stutter. That's unacceptable, and if you're trying to load 100 actors, it's going to crash your app.

So, staggering spawns of actors WORKS just fine if you don't have a large list of rules the actors go through. I know some objective -c and I can tell you that there is something very buggy going on with this. Possibly storing of RAM after each rule is determined to not be in effect. This would normally need to be flushed, but instead they stick around until you reset the scene or restart the application.

Next is that having a large amount of actors will up your load time. I've been working with an app and attempting to keep a load time of around 7 seconds on a 4th gen ipod touch. This translates to about 13 seconds on an iPhone 3g. Adding in 100 actors (with a single tiny image used in each one), the load time went up but about 5 seconds. Keep in mind that these actors are not even in use in the actual game. They are just sitting in the actor pool. The biggest thing I learned from this was to get rid of every actor that you don't absolutely need. Even if they aren't used they are eating into initial load time.

Also I've noticed the power of the device processor is diminished when using viewer and sending info back to your mac. This is kind of a nice thing to know because it means you're actually getting very slightly better results when not running through viewer and sending info back.

I know this is probably a little long winded, but I like having more information than I need rather than scrapes from multiple places. Essentially what I've found is this:

Even the no-no's of GS behaviors won't significantly crush resource usage if used sparingly. In fact, often times they can help by taking time away from the initial load time.

Staggering spawning of actors works very nicely to reduce load time, but make sure the actors you spawn don't have any rules in them that change their attributes based on location (or possibly any other variable). If you think about it, it would take less time to load and initial 50 megs of RAM rather than 60. So stagger out the last 10 megs throughout 20 or more seconds after the game loads. The user won't know what's going on while they are playing, and the load time they have to deal with will be less. If it's just a straight up spawn of an actor, there won't be a lot of repercussions to deal with in terms of RAM. This only works with relatively small amounts of actors to spawn. In my experience you can spawn about 10 actors, each on their own second or half second, over a hundred times without any visual notice to the user.

Keep organized and experiment a lot. And share what you find that works, even the little things. It doesn't matter if someone thinks what you write is insignificant or obvious. It won't be obvious to SOMEONE out there, and that's the person that you're writing for.

Good luck to you, and to me!

jonmulcahy

entersimon, that is some great information there, and really deserves it's own thread instead of replying to one a month old. would you mind creating a new thread called optimizing or something? Otherwise it will get lost and people won't find it during a search. I'm going to close this one down.

entersimon

sure thing, I just like replying to these threads because they show up in google searches. I'll go ahead and make a new one now.

jonmulcahy

yea, we want to keep down replying to threads over a month old down to a minimum. most of the time the original information is outdate and get's people confused