Web Player Streaming is critical for providing a great web gaming experience for the end user. The idea behind web games is that the user can view your content almost immediately and start playing the game as soon as possible instead of making him wait for a progress bar. This is very achievable, and we will explain how.
This section will focus on publishing to online game portals. Streaming is useful for all kinds of contents, and it can easily be applied to many other situations.
Online game portals expect that some form of game play really starts after downloading at most 1 MB of data. If you don't reach this makes it that much less likely for a portal to accept your content. From the user's perspective, the game needs to start quickly. Otherwise his time is being wasted and he might as well close the window.
On a 128 kilobit cable connection you can download 16 KB per second or 1 MB per minute. This is the low end of bandwidth online portals target.
The game would optimally be set up to stream something like this:
The key point to keep in mind is to think in wait times for a user on a slow connection. Never let him wait.
Now, don't panic if your web player currently is 10 MB. It seems daunting to optimize it, but it turns out that with a little effort it is usually quite easy to structure your game in this fashion. Think of each above step as an individual scene. If you've made the game, you've done the hard part already. Structuring some scenes around this loading concept is a comparative breeze!
If you open the console log (Desktop Platforms); menu OSX) after or during a build, you can see the size of each individual scene file. The console will show something like this:
button in the Console window(***Player size statistics*** Level 0 'Main Menu' uses 95.0 KB compressed. Level 1 'Character Builder' uses 111.5 KB compressed. Level 2 'Level 1' uses 592.0 KB compressed. Level 3 'Level 2' uses 2.2 MB compressed. Level 4 'Level 3' uses 2.3 MB compressed. Total compressed size 5.3 MB. Total decompressed size 9.9 MB.
This game could use a little more optimization! For more information, we recommend you read the reducing file size page.
Streaming in Unity is level based, and there is an easy workflow to set this up. Internally, Unity does all the dirty work of tracking assets and organizing them in the compressed data files optimally, ordering it by the first scene that uses them. You simply have to ensure that the first levels in the Build Settings use as few assets as possible. This comes naturally for a "menu level", but for a good web experience you really need make sure that the first actual game levels the player is going to play are small too.
In order to use streaming in Unity, you select Web Player Streamed in the Build Settings. Then the content automatically starts as soon as all assets used by the first level are loaded. Try to keep the "menu level" to something like 50-100 KB. The stream continues to load as fast as it can, and meanwhile live decompresses. When you look at the Console during/after a build, you can see how large
You can query the progress of the stream by level, and once a level is available it can be loaded. Use GetStreamProgressForLevel for displaying a progress bar and CanStreamedLevelBeLoaded to check if all the data is available to load a specific level.
This form of streaming is of course linear, which matches how games work in most cases. Sometimes that's not enough. Therefore Unity also provides you with API's to load a .unity3d file manually using the WWW class. Video and audio can be streamed as well, and can start playing almost immediately, without requiring the movie to be downloaded first. Finally Textures can easily be downloaded via the WWW class, as can any textual or binary data your game might depend on.
Page last updated: 2012-10-12