Lysis blog

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.


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.


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.


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.


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.


posting by LaRue (contemporary space otter) Wednesday 24 November 2010
Another method I found to decrease loading time and server bandwidth usage (AS3
only) was to use a bytearray.  It's outlined here:
Essentially what it does is creates a bytearray of the .swf file and then allows
you to play these bytes back as the normal .swf.  Tonypa said that it can be used
to make it more difficult to get at your source code (barely) but you can also
store the bytearray as a shared object.  That way if the player has played the
game before, you can grab the bytearray from the shared object and use that
before loading the .swf from the server that has the full game in it.
A comment was deleted on Tuesday 4 October 2011.
posting by AnatoliyLes (vociferous curly owl) Wednesday 12 October 2011
Sorry i new user . plz help to create new topic
posting by Lysis (site owner) Thursday 20 October 2011
This isn't a full bulletin-board system, it's just for article comments.
However, a general comments thread seems like a good idea, so I'll create one in
the near future.
posting by Jamesutup (adventurous moon tortoise) Friday 7 February 2020
Deleted - spam
posting by Sandrasmism (honourable shadow knight) Wednesday 18 March 2020
Deleted - spam
posting by Sandrasmism (honourable shadow knight) Tuesday 24 March 2020
Deleted - spam
posting by Sandrasmism (honourable shadow knight) Sunday 19 April 2020
Deleted - spam
A comment was deleted on Saturday 18 July 2020.
A comment was deleted on Wednesday 11 November 2020.
A comment was deleted on Saturday 14 November 2020.
Add a comment (Please read the notes before submitting your first comment)
no registration required
re-use handle & password to retain identity


Back to Lysis Games main page

Back to Lysis Blog