This unit itself is just an overview. We'll try to paint a high level picture of what a data-drive game engine looks like, and draw out the roadmap for the entire class.

Here's a quote from a colleague I heard a long time ago - "Game development is a bunch of engineers coding systems for what they're designed to do just to make then do what they weren't designed to do when designers change their minds"

My friend was being facetious, but the truth in his message is that building a game engine is an epic battle of fidelity and features against iteration, deadlines and other constraints.

Our goal here is to try craft an engine with a data-driven architecture, so that it provides a core foundation for the game(s) we are planning make along with room to adjust course. We really want to build up the systems in a way such that they are data driven enough to help support quick iteration of gameplay. Do we need to be a hard-ass about our structure? No, we just need to do our best to create natural boundaries and focus on workflow rather than getting caught up in over-engineering a project.

Purposes/Benefits of a data-drive Game Engine

• Re-usable code!
• Reduced code size (While this is true in bigger projects, smaller projects it isn't necessarily true)
• Encapsulation - game code doesn't have to know anything about hardware or browsers or third party API's
• Specialization - breaking down components of the engine so that the people best suited for a system can work on it
• Exposing key features to designers and artists and formalizing workflow between disciplines
• Reducing risk, both technically and for design
• "Content is king!"

Web-based Game Development

Web-based game development is very different than industry standard game development.

• Middleware and tools are abundant so developers hardly ever start from scratch.
• Production techniques are in place for scaling and directing workflow for larger teams.
• Web developers going into game development often stick to web app development paradigms.
• Web games can have a much longer lifespan!
• Web development only recently got powerful enough hardware and interpreters for robust JavaScript based games. Still a very young industry compared to native game development.
• Very few people cross the web-developer and game-developer worlds, meaning that there are not very many resources for either to become good at the other.

We're going to be using Web technology, but sticking to more industry standard patterns because the purpose of this class is to focus on game development and we're only using HTML5 and JavaScript as a vehicle to do so.

Some questions you'll still need to ask regardlessly:

• Genre? or major game design features?
• Target audience?
• Skills/talents of the development team?

Dan Cook's excellent blog - Managing game design risk: Part II - Data Driven Development

Gamasutra article - GDC: God of War: How the Left and Right Brain Learned to Love One Another

To build a data-driven game engine, we have to breakdown all the complex interactions of systems that get tangled together. There are a lot of problems to solve, so it's best if we divide the issues up and deal with them independently.

This is just an overview so you have an idea of what the disection of a general purpose game engine looks like. During this class you will be building many (but not all) of these pieces yourself, pulling them together yourself, making the picture even clearer.

Engine Core

• Manages the gameloop, ticking all the subsystems
• Simple model: Sample Input, Update Game Entities, Render the Scene
• Complex model: Handle Elapsed Time, Sample Input, Update Networking messages, Update Physics Simulation, Update Animation, Update Game Entities, Render the Scene

Game Object System

• Game Objects, Events, Components
• A Game Object is mostly a utility object that handles the adding and removing of components
• Components add features to a Game Object, such as animation or physics
• Events work great in JS, allows for communication between systems, between objects, or between components

Canvas Management

• Manages the render context, which is what is displayed to the user.
• Support multiple canvases, or off screen canvas

Asset Management

• Asset pipeline is an important part of a game engine, especially working with Artists
• Provides a consistent interface for accessing game resources
• Centralize resource loading so gameplay can reference a single loaded instance by ID
• Ability to load and unload resources at run-time (AJAX)
• AJAX calls are used for loading assets at run-time, and this needs to be done through a web server (for local testing we can use something like Mongoose).

Scene Management

• Storage for level data, player objects, enemy objects, dynamic things like bullets or collectables
• Loading and unloading of world data

Camera systems

• Interacts with the renderer to control what's viewable. Could follow an object, or zoom in and out.
• Pretty simple in 2D games; behavior can be very extensive in 3D games

Sprites and Animation

• We're focusing on 2D Sprite Animation. Others types used in games are: Skeletal animation, vertex animation, Inverse Kinematics
• Draws entire images, or switches through clipped rects from within a single image to do animations.
• Updates the current frame of objects based on their playback speed and other parameters.

Audio System

• Adds ability to play/stop music files
• Adds support for triggering audio sfx, possibly parameterizing them (random pitch for variation)
• Storage of SFX data (audio file(s) to use, configuration parameters like volume, pitch), can be referenced by name
• This is probably the biggest weakness of HTML5 in terms of robust or uniform vendor support

Input

• Manages input from Keyboard, Mouse, Touch, Gamepad.
• Typically polls for input, or waits for events from the browser.
• Provides a data abstraction so that the game can connect specific input events to the game's "action" events
• Stores input values for gameplay code to check against, or sends input events to registered handlers

Physics system

• Various ways to do game physics: Simple "pinball" style physics, 2D Grid physics, Rigid body dynamics
• Rigid Body Dynamics - Motion (kinematics) of rigid bodies and the forces (dynamics) that cause motion
• Updates the physics world (integration of forces to determine objects' positions)
• Checks for collisions between objects based on their shape (circles, boxes, triangle meshes)
• Resolves collisions so solid objects react believably (moves objects so they do not penetrate, sets velocities based on desired behavior: bouncy ball, heavy brick)
• Stores contact information so gameplay can react to it (deal damage, activate switches)
• Advanced features: Constraints, Raycasting, Triggers, etc

Networking

• Typically a HUGE undertaking with native games. Has profound design implications for almost all engine components.
• Have to support a variety of network conditions, and make decisions based around real-time vs. asynchronous.
• The game engine acts as a client application that communicates with a server application
• Could possibly communicate with other client applications
• Other considerations: Server authentication, Client-side prediction, and lots of messaging

Lots others...

• Memory management (JavaScript is already a memory managed language, so less of a concern for us)
• Hardware abstractions (important for console development)
• Math Library (vectors, matrices, quaternions)
• Container Library (linked list, vectors, trees)
• Debug and Profiling Systems (runtime/ingame variable watching, profile sampling)
• Unit Testing
• Visual Effects (particle systems)
• Advanced Rendering Systems (customizable shaders)
• Cinematics / Video playback
• HUD/UI Systems