Game Development Reference
In-Depth Information
than local disk access. Since network streaming is the slowest access time,
T(L)
should properly represent the time to load an asset based on specific bandwidth
capabilities.
Second is the time,
t
, at which assets are requested. Time was loosely defined
above because gameplay time can vary by the type of gamer. In practice, you
might want to average the gameplay time by taking a sample from your testers
and excluding the outliers. With this average time determined, the game designer
and artists can tune the game to try and achieve a no-wait, instant-play scenario.
It might be dicult to tune the game load times to a player who has the lowest
gameplay time. However, if assets are cached on disk locally after being streamed,
then it might be possible to allow for instant play on subsequent plays even for the
best of gamers.
Third is the actual assets themselves. Not all games are deterministic, so the
time at which an asset is needed varies based on a specific play-through of the
game [Thall 09]. One approach to this situation is to average the times at which an
asset has been requested over cumulative play sessions during the development of
the game. Another approach is to have a completely different load sequence based
on characteristics of a play-through (e.g. starting location, player experience level,
etc.). A third approach is the combination of the first two approaches, which is to
have different load sequences that are based on an average of similar play-throughs.
Finally, if there were a completely alternate set of assets depending on the graphics
capabilities of the client machine, then that needs to be treated as a separate
case.
Fourth is the granularity of the assets themselves. While it might be possible to
package each asset individually for transfer over the network, there can be inherent
overhead with that approach. For this reason, assets are usually grouped into
bundles. What assets are bundled together depends upon the game being made.
Sometimes, it makes sense to group assets by type, such as having multiple textures
grouped together into one bundle. Other times, it may be more ecient to group
bundles based upon their usage in the game, such as having all assets for a character
bundled together. In general you want to pack as many assets as necessary inside
each bundle to minimize the overhead with each asset bundle and its associated
request.
The final consideration is the need for asynchronous requests. If requests were
completed synchronously, then the game would halt every time an asset was re-
quested. Any game that wants to achieve instant play needs to hide asset requests
asynchronously [Kreigshauser 10]. So, instead of game code like this:
Texture2D albedo = AssetManager.LoadAsset("character/tex/albedo");
//Do something with albedo
