2D Game Engine Development in HTML5

Textbook readings

Camera Component - Code

The camera is a component that gets added to a Stage entity

CODE - Camera component

Camera System Features

Input Module - Code

The Input module takes care of wrapping keyboard, mouse, touch, and gamepad events, and connecting them to our game

CODE - Input Management

Input System Features

Animation Module - Code

Another layer of data abstraction

Sprite Sheets are great at storing multiple images in a single file, and also multiple frames of the same sprite

We need a way to say which of those frame are used for running, and which are for walking, and which are for standing, etc

And other properties along with frames: how fast is the running playback, any events to trigger, whether to loop or transition into a next animation, etc

CODE - Animation Module

CODE - Animation Test

Animation System Features

2D Physics - Overview

The Blockbreak demo game does pixel-perfect collision checks with bounding boxes, but doesn't support rotations or have great collision reactions.

We could program equations of motion for each object as needed (ie, arrows, bullets), but a more general solution is ideal.

If we want our game to have a variety of collision shapes, robust collision response (bouncing, sliding, rotations), and more believable movement, then we need a Physics Engine.



Desired System Features


Linear motion

  • Very similiar in 2D and 3D!
  • position is a vector, representing a 2D point in space.
  • velocity = change in position over time (meters per second, m/s)
  • acceleration = change in velocity over time (meters per second per second, m/s^s)
  • Assume constant acceleration, because otherwise our math will get too hard!

Angular motion

  • Thank goodness we're in 2D!
  • orientation is the direction that the object is facing, represening a 2D angle (scalar)
  • A vector orientation representing the facing direction - { x: cos(angle), y: sin(angle) }
  • rotation is a change in orientation (to rotate an object is to change it's angle)
  • angular velocity = the rate of change in orientation (radians per second, also a scalar)
  • angular acceleration = the rate of change in angular velocity (radians per second per second, also a scalar)
  • Radians are unitless!
  • Center of Mass / Center of Gravity / Origin
    • Objects is in many locations at the same time: it covers some extended area.
    • Locations on the object are given relative to the origin of the object, so that it's the same regardless of rotation (car headlight is ahead of the center of car). Equations for converting a relative point to an absolute point is called a "transformation from local space to world space"
    • When the center of mass is the object's origin, then physical behavior can be decomposed into the linear motion of the center of mass, and the angular motion around the same point. (Involved proof, I'll explain later)

Newton's Laws of Motion

  • 1) An object with no other forces will maintain velocity
    • Technically he said momentum, which is the product of velocity and mass. Since mass is constant for linear movement, we can just work with velocity. For angular movement we'll have to worry about this.
    • In the real world there are forces slowing down moving objects (eg. air drag), which we simulation using damping. Each frame when we integrate, we will remove a portion of the object's velocity to simulate drag. 0 means no velocity is saved, 1 means all is saved.
  • 2) The acceleration of an object is calculated by the net forces acting on it and the object's mass: F = ma
    • Two objects experiencing the same force will behave differently depending on their mass
    • If we want to drive a game object by forces, then we need to integrate: a = F/m.
    • If an object has 0 mass then we'd have division by zero, so use that to imply that the object has infinite mass, meaning we do not bother calculating it's motion based on forces.
    • D'alembert's principle tells us (through grand simplicification) that we can replace a set of forces with a single force that is the sum of all forces.
    • Gravity is funny: calculation is based on both the mass of the attractor and attractee. Since the earth is so huge, the difference in mass for our rigid bodies is neglitable, so we can simulate gravity as an acceleration.
  • 3) For each action there's an equal and opposite reaction. When a body collides with another body, we need to calculate the amount of force that occured in the collision so both bodies can react.
    • A lot of the difficulty is determining where two objects touch or are connected.
    • We can use 'contact forces' to keep objects from interpenetrating.

Solving the equations of motion backwards, Integral Calculus!

  • We use an "integrator" to update the position and velocity of each object.
  • Given a time interval over which to update an object: position = position + velocity * dt + acceleration * (dt^2 / 2)
  • Known as Euler's Equations of motion. It's not very accurate and generally not used. We have Runge Kutta, Verlet, and few more to choose from.
  • Further reading: Integration Basics
  • Further reading: How important fixed timesteps are

Box2Dweb to the rescue

Physics Module - Code

Add physics functionality through components: one for the stage representing the physics world, and one for our sprites representing rigid bodies

Default properties are stored ahead (helpful when referencing what parameters we can set when writing game code)

CODE - Physics Module



API Concerns: When do we need to account for world scale? Prepare for bugs related to this.

API Alternatives: Could the Box2D world live on the engine and not on a scene?

API Alternatives: The actor component could extend some of the utility functions onto the entity?