• Chapter 10 - Canvas, Asset Manangement
• Chapter 11 - Sprites, Scene management

Centralized access to rendering context, in this case Canvas (but could be SVG or just DOM)

CODE - Canvas Management

Canvas System Features

• Our Engine: Requires JQuery libraries
• Setup method is simple with what it does, but complicated because it's flexible:
  • Grabs a container from a passed-in ID
  • If it can't find an element, then it creates a new <canvas> tag
  • It then creates a wrapper element used to center the element on the page with a default size.
  • Checks if the element has a getContext method, and if so grabs the 2D context and stores it for rendering
• Size can be configured. Support for resample sizes (helpful on mobile)
• Clearing the canvas
• Getter function, so sprites can draw themselves

General purpose asset loader

Want to be able to load any assets during the game, ie a loading screen, level transition, etc

Support for loading image files, audio files, json data files

Refer to asses by a resource name that is different than it's filename

CODE - Asset Management

Test Code for Asset management

Asset System Features

• Our Engine: Requires Underscore and JQuery libraries
• Static objects and functions, helpers for determining asset types
• We assume different file paths per asset type, which is configured by the Engine options
• load
  1. Converts asset list into a consistent format
  2. progress callback for each item (if user wants a loading bar)
  3. Loop over asset hash, determine type, dispatch appropriate loader function
• queueLoad
  • Textbook calls this preload, but I don't like that name (preload implies the files begins loading asap but doesn't block)
  • Allows the engine/user to queue files from anywhere in code (decentralized) and then at a specific point tell them all to load

Primary visual objects, based on GameObject/Entity, used for displaying graphics

Data driven system, to enable future support for building more robust animations

Our Engine: Requires Underscore library

CODE - Sprite Module

Test Code for Sprite management

SpriteSheet class

• Allows any number of images to be stored in a single image, making the game quicker to load and animations easier to work with.
• Builds up support for animating a sprite, by letting it switch through which frame of an image it is using to render.

Sprite Entity class

• We reference assets/sheets by name instead of storing the object directly, so that the sprite class is serializable.
• Adding an ID allows us to store and pass around objects by identifiers instead of actual references, making gc and network syncing simplier.

Sprites Engine Module

• Adds SpriteSheet management features to the Engine
• Centralized mechanism for compiling and tracking sheets to make them easy to reference and lookup.

Responsible for keeping a list of objects and handle the adding or removing of them.

In charge of looping over that list for any given purpose (stepping, rendering)

Has a .step() and .draw(), so we can control updating and rendering entire groups of objects at a time.

Could be responsible for checking collision between objects.

Our Engine: Requires Underscore library

Examples:

• Setup levels and switch between levels.
• Layered game interfaces. An RPG could have a inventory screen on top of the game screen while the game is paused.

CODE - Scene Module

Test Code for Scene management

Scene Class

• Used to set up a stage object into a particular stage
• Very simple, just wraps a function that can create and add objects to a scene

Stage Entity Class

• Manages the updating and drawing of many sprites
• Add/Remove objects.
• Helper functions for performing an operation on all objects in the scene.
• Support for pausing independently of other stages.
• Checks for collision between sprites.

Scene Engine Module

• Add new scenes by name, which just stores it to be used when needed
• Staging a scene, which creates a new stage so that all objects in it can be updated and rendered.
• Support for a registering a default game loop.