HTML and CSS Reference
In-Depth Information
Physics Engine
In making an HTML5 game, it is vitally important that physics is well represented within the experience.
There are a number of solid-state physics engines available that have been successfully used in a multitude of
games. However, when we are talking about working in the mobile Web, there can be major problems. The number
of calculations required to deliver constrained, rigid body physics isn't conducive to rendering a game well on a
lesser device. The JavaScript game loops need to assign as much of the performance budget as possible to the render
cycle; any excessive “juice” being burned by a physics engine could mean constraining your product to use on only
the top-end devices and failing to reach as many users as possible.
To mitigate this, in
Funfair Freak-Out
we employed a bespoke physics engine. In the most basic cases, it is
possible to implement physics in a couple of lines of code—apply some gravity to an object's velocity, and presto.
In this case, there had to be a fair amount of sophistication; we certainly required a system that would allow for
collision detection, motors, and moving platforms. What we really needed was to minimize the number of square root
calculations required in each game loop. A line intersection model afforded that option.
A simple, classic system would be to use bounding boxes. The drawback here is that the scene then has to be
constructed out of blocks, lessening the capability of having organic shapes or slopes and slowing down the level
design process.
Line-to-line, rather than box-to-box, intersection gave us the sophistication we were after.
By using a combination of linked lists, bounding boxes, lines, and edges, it is easy to draw scenes that feel organic
and natural, with negligible processor overhead.
The base primitive object in the system is the edge, a simple connection between two points. A linked list
collection of connected edges can form a line. The line has a bounding box. Now, I can move scene actors around
with a first pass of looking at the bounding boxes. If and only if a collision is detected does a test run for line
intersection (see Figure
14-5
). Doing comparative tests using a single point is dangerous. This could allow an actor to
fly through a collision without realizing the possibility of an intersection. But, if I take the velocity of the actor, I can
create a bounding box around the start and end points. This will never miss an intersection.
Figure 14-5.
Using line intersection rendering
So, the system discovers an intersection. Now, the link list is parsed through, and the edges are calculated for
line-to-line intersection. The test is simple and works as follows:
•
The whole coordinate system is translated to ensure that the actor's start point is at (0, 0)
(see Figures
14-6i
and
14-6
ii).
•
The system is next rotated so that the actor's travel is along the x-axis (see Figure
14-6
iii).
