19th June 2010
Minimising subjective download time - part 2
Last time I described how to make sure your game doesn't have any blank period before the preloader. Here I cover some of the more interesting ways in which you can entertain the player before your game has completely loaded.
The basic approach
One fairly common way to reduce the bordom associated with loading delay
is to add intricate detail to the loading screen.
I'm not referring to sponsor-branding intro animations (which are in any case beyond
your control), but rather the game-specific loading screens; generally modifications
of the loading bar.
I don't want to say that there's no place for this, but I suggest that it is often
a sub-optimal approach. Okay, so the player may be more entertained watching
a character walking along the loading bar, but the time spent developing that is not
really adding to the game proper.
Advert
While U Wait
The ubiquitous preloader method is really the lowest common denominator. It may
be easy to implement, it may ensure that the game works, but by using it you are
essentially wasting the streaming potential of Flash files.
By using 'staged' loading, you can show your player the tutorial, ask them if they
want the sound on, supply tips for the game or anything else you can think up.
Some of these may only be useful the first time the game plays - but that is
the important time! Realistically, few online games get a second load, and if they
do it's because the player has already decided they like your game.
The distinction from the loading animation mentioned above is that these are
generally things the player will need to do anyway.
For a multi-loading tutorial, it is important to plan your approach. You need to present information to the player in an understandable order, but also to have the data available part-way through loading. If a display needs the whole game to be loaded first, you can't use it until the end.
So what is required to make this work? Not very much extra, actually.
One way of doing it is to create a general-use preloader which will wait for a
specified frame, and go to it when it has loaded. Call this preloader every time you
need to move on, passing the next target frame. If your tutorial screens are
relatively small this might be considered overkill, but it is very efficient in terms
of code too. Make this preloader test for target-frame availability before displaying
itself to avoid an annoying glimpse of it between pages.
One frustrating aspect of implementing this is that you can't use frame names, since by
definition you can't assume that the target frame has loaded. This means hard-coding
frame numbers, which makes rearranging frames more fiddly. Therefore, planning your
data is that much more important. It is a good idea to include extra blank frames between
stages for when you realise you've missed something.
It is essential to be very clear that the game is still loading - show a loading bar in the same place on every screen. If you do not, players may skip through the tutorial just to end up waiting for the game to load - or worse, get annoyed at the slow response to their clicks. You may want to arrange for your 'continue' buttons to only display once the target frame has loaded.
If you want to show anything just the first time the game loads, you'll need to record
when it's been seen in a sharedobject. Rather than flagging a tutorial as 'seen' immediately,
consider testing for some early success in the game instead, such as completion of
level 1. This is slightly more friendly to players who do not see or understand everything
first time.
Further to this, make sure that players can redo the tutorial if
they want to - you'll still need that 'instructions' link on the menu screen.
Advert
Early entry
The above section covers how to entertain the player while the game loads. Besides this, it may be possible to begin the game before it has completely loaded. If your game has a large amount of level-specific data, you may be able to put level 1 in an earlier frame, and leave the preloader at that point. This does unfortunately increase the complication of your game logic slightly - unlike graphic or aural assets, you need to visit frames to collect code, and check you've loaded enough to proceed before starting the levels. So it's only really worth it if you've got megabytes of localised data.
A common player request in flash games is for more variety in music. Of course this is easy to dismiss as naive, since this is without regard to constraints like cost or loading time. I doubt the people asking for this in my games realise that the single music track included represents 80%-90% of the file, for instance. However, it's worth bearing in mind that if you are willing to start without music, or with just the first of several tracks ready, this is an opportunity for rapid play. I hope to have more to say on this in the near future.
Multi-tasking
Another possibility, which is also a size-optimisation, is to render assets while the
rest of the game loads. You're not taxing the processor by updating a loading bar, so why
not use some of the wasted cycles to reduce the amount you actually have to load?
This is especially useful if your data is programmatically generated
from flash anyway, since all you have to do is set it up to run under interrupt.
In my game Distortion Factor I used this for a distortion map which would not compress
well as a bitmap.
A final word of caution: in all cases, consider whether the potential saving is
worth it. If your game is huge then not only are there large potential time savings
to be made, but also you are mitigating a distinct disadvantage.
On the other hand players (and sponsors) don't notice when an average-sized game starts
a fraction more quickly than normal. You'll never get positive comments about loading
time, you can only avoid the negative ones.
Postface
In this pair of articles, I've covered ways to reduce the time spent waiting for
the game to do something interesting. Admittedly some size-optimisation crept in
at the last minute, but I decided it was necessary for full coverage of what I think
is an under-discussed topic.
If I've missed anything, or you disagree, you are as usual welcome to leave a
comment below.
Advert
Comments