CycleBlob: A WebGL Lightcycle Game - HTML5 Games Most Wanted - page 205

All the efforts invested thus far in loading and generating models, animating them, and lighting them
culminate into a single, rendered frame. This function tells WebGL to communicate with the graphics
hardware and kick it into action. In most modern machines, this is where the majority of the time the
tick() call is spent. Anything else the game does takes a fraction of the time the rendering takes.
In Firefox and Chrome, the currently stable WebGL implementation, calling requestAnimationFrame()
repeatedly when the tab is active maintains a frame rate of approximately 60 fps. This is generally
considered the upper frame rate bound since most modern LCD displays cannot refresh at a higher rate.
(This is in contrast to older CRT displays, which could reach refresh rates as high as 120 fps.) For 60 fps,
a call to tick() should occur approximately every 16 ms. This optimal frame rate can be maintained only
as long as the tick() call returns in less that 16 ms. If it doesn't, the next call can't be triggered. Since all
of JavaScript events are triggered from the same OS thread, if that thread is busy executing the previous
call to tick() , it will lag in handing the next call and the effective frame rate would decrease from 60 fps.
Anything done in tick() should be extremely efficient and anything that can be performed in a pre-
processing stage should be done at that time.
Data structures
The flow of data in CycleBlob is fairly straightforward. Several global objects hold all of the persistent
information the game uses and maintains. A brief discussion of the major ones follows.
var resources (loadManager.js) : A repository that maintains a list of resources that were
downloaded from the server using XmlHttpRequest and possibly processed in code. Currently, the
resources managed here are only mesh models, but the name of the variable implies possible future
extension for other resources, like audio files and images. Every resource has a name and before
using a resource, the code needs to check that it actually exists. If it doesn't, then the resource
needs to be downloaded and possibly processed before it can be used. Grid models are
downloaded in batches of three at a time, for the next three levels the user is going to play. After the
player advances to the next level, the processed grid model is removed and reclaimed by the
garbage collector to avoid a heavy memory footprint.
var levels (gameControl.js) : Defines the core parameters for every level of the game. This
includes the URL to the grid model that needs to be downloaded, the number of players
participating, and the level of artificial intelligence they have. This data is never changed and is
considered to be constant.
var players (main.js) : This holds a list of the players (human and artificial intelligence) that are
currently participating in the game. The Player object ( player.js ) contains everything there is to
know about a player, as follows:
Whether it is alive or dead
Its color
A reference for the bike model from the resources repository (a future version may have different
bike models for each player)
Parameters required for movement and animation: forward direction, normal, and the A, B, and T
parameters
A Wall object that holds the model of the wall trailing behind the player