Before you write a single line of JavaScript, a browser game needs a plan. Game design fundamentals are about answering a handful of deceptively simple questions: What is the player trying to do? What rules govern success and failure? What objects exist in the world, and how do they relate to one another? How does the player act on the game, and what does the game show back? Writing these answers down — in a short design document or a rough sketch — turns a vague idea into something you can actually build in a few weeks.
In this course, design discipline matters mostly because of scope. A browser game built on Canvas with a single game loop can support a surprising amount of play, but only if the entity list stays small, the rules stay clear, and the win/loss conditions are decidable in code. Deciding early that you have a player, a set of obstacles, a score, and two end states makes the later work of looping, rendering, input handling, and collision detection far more straightforward. Changing your mind about the core objective halfway through does the opposite.
The videos below come from game designers rather than web programmers, so treat them as sources of design thinking, not implementation detail. As you watch, listen for how designers talk about a core mechanic, how rules create interesting decisions, and how constraints improve rather than limit a project. Then translate what you hear into your own one-page design: objective, rules, entity list, interaction model, and a sketch of the screen.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
The HTML5 Canvas element gives you a blank rectangle of pixels in the browser and a JavaScript drawing context (usually obtained with getContext('2d')) that lets you paint on it. Everything a player sees in a Canvas game — the background, the character, the obstacles, the score text — is drawn by your code, one shape or image at a time, and then erased and drawn again a fraction of a second later. There is no DOM element for the player's character; there is only what you drew on the most recent frame.
In this module that matters because Canvas drawing is the output half of your game. You will set up the canvas and its size, establish the coordinate grid (origin at the top-left, x increasing to the right, y increasing downward), layer a background, draw rectangles and images for obstacles and objects, and cut frames out of a sprite sheet with drawImage to animate a character. Then you will clear the canvas with clearRect and redraw everything so that motion appears smooth rather than smeared.
As you watch the videos below, pay attention to a few recurring details: how the canvas is created and sized in HTML versus in JavaScript, how each drawing call translates numbers into positions on screen, the order in which things are drawn (background first, foreground last), and where the clear-and-redraw step sits inside the animation loop. Try pausing and recreating small pieces in your own file — a filled rectangle, an image at a given x and y — before attempting a full game.
A walkthrough of building a complete Stick Hero-style game using plain JavaScript and the HTML Canvas 2D context. Based on the title and description, it covers setting up the canvas, drawing the game world (platforms, the stick, the character) as shapes, and redrawing the scene as the game state changes. It is a condensed, project-oriented tutorial rather than a reference lecture.
Because the whole game is drawn with Canvas primitives, it is a strong demonstration of the coordinate grid, layered drawing, and clear-and-redraw cycle in a real project; Hunor Márton Borbély is known for clean, well-explained Canvas game tutorials.
The opening part of a series on recreating a Street Fighter style game with JavaScript and HTML Canvas. This first episode focuses on the plan for the project and the tooling and setup needed to get started, which typically includes creating the canvas element, sizing it, and getting the 2D rendering context before anything is drawn. It frames the scope of the game before code is written.
It models the "set up the canvas element and plan the game first" step that opens this topic, and it previews how background, characters, and objects will later be rendered in the same drawing surface.
A focused tutorial on sprite animation in JavaScript using the Canvas element, part of a larger game-building series. It deals with sprite sheets — single images containing multiple animation frames — and how to draw the correct frame onto the canvas so a character appears to move. Expect discussion of frame indices, source rectangles, and timing the frame changes.
This is the most direct coverage of rendering character sprites, and it shows why the canvas must be cleared and redrawn each frame for animation to look right rather than leave trails.
Together these videos build the drawing layer that the module's outcomes depend on. The Street Fighter intro supports MO1 by showing a game being scoped and set up before code is written; the Stick Hero build and the sprite animation episode both demonstrate the clear-update-redraw cycle at the heart of MO2, including how every visible element is re-rendered on each frame. Watching complete game projects also previews MO3 through MO5, since input handling, collision and scoring logic, and final assembly all operate on the same entities and coordinates you learn to draw here; master the drawing and the grid first, and the later subsystems have something concrete to act on.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Every browser game, no matter how simple, is driven by a loop: a function that runs over and over, updating the positions and states of game objects and then redrawing the screen. This is the game loop, and it is the heartbeat of the project you are building in this module. Without it, a Canvas drawing is just a static picture; with it, the same drawing code becomes animation.
In JavaScript, the preferred way to drive that loop is requestAnimationFrame. Unlike setInterval or setTimeout, it asks the browser to call your function right before the next repaint, which produces smoother motion, synchronizes with the display's refresh rate, and pauses automatically when the tab is hidden. You will write a core loop function that clears the canvas, updates game state, draws everything, and then schedules itself again. You will also learn to store the loop's ID so you can stop it for pausing or for a game-over screen.
The subtler issue is timing. Because different machines and monitors run at different frame rates, movement expressed as "add 5 pixels per frame" will run faster on some computers than others. The fix is delta time: measure how much real time passed since the last frame and scale movement by it. As you watch these videos, pay attention to three things — how the loop schedules itself, where in the loop state is updated versus drawn, and how timestamps are used to make motion independent of frame rate.
This video walks through a template built to display frames per second in the browser, and in doing so compares requestAnimationFrame with the older setInterval approach to timed animation. Expect discussion of why frame rates vary, how FPS is measured by tracking elapsed time between frames, and what each scheduling method does differently. The context is a Tumult Hype template, but the underlying JavaScript concepts are the ones you will use in your own loop.
It directly addresses the requestAnimationFrame versus setInterval decision at the center of this topic, and the FPS counter angle makes frame timing concrete, which is the foundation for understanding delta time and frame-rate independence.
A focused tutorial on JavaScript animation fundamentals that builds up an animated example using requestAnimationFrame. It covers the basic structure of an animation function that updates values and then re-schedules itself, which is exactly the shape of a core game loop. The short runtime keeps it close to the essential mechanics rather than wandering into unrelated features.
It is the most direct match for the subtopics on introducing requestAnimationFrame, writing the core loop function, and updating state each frame, presented as a hands-on coding walkthrough you can follow along with.
This video explains how the Source game engine handles ticks — the fixed-interval updates that advance simulation state — and why tick rate affects gameplay behavior. It references the well-known "Fix Your Timestep" article, which is the standard reference on separating simulation updates from rendering frames. The examples come from commercial games, but the problem being described is the same one your delta-time code solves.
It gives useful context for why frame-rate independence matters beyond the browser, showing real consequences when update timing is tied to frame rate, and it points you toward the canonical timestep reference.
Together these videos support MO2 most directly: the requestAnimationFrame tutorials show how to write a self-scheduling loop that updates and redraws every frame, while the FPS and tick-rate videos explain the timing measurements behind frame-rate independence. Because the loop is where updates happen, this material also underpins MO4, since collision checks, scoring, and win/loss tests all live in the update phase you are learning to structure here, and MO5, since the loop is the component that ties drawing, input, and game logic into one running program.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A game is only a game when the player can act on it. Everything you have built so far — the Canvas drawing calls, the state object, the requestAnimationFrame loop — runs on its own schedule. Event handling is the bridge that lets a keypress, a click, or a finger tap reach into that loop and change what happens on the next frame.
In this topic you will attach listeners to the document or directly to the canvas element, read the properties the browser hands you (key codes and key names from keyboard events, coordinates from mouse events, touch lists from touch events), and convert those raw values into game-meaningful actions such as "move left," "fire," or "aim at this point." A common and important pattern is to record input into a state object rather than acting immediately inside the handler, so the game loop stays the single place where the world updates. You will also learn when to call preventDefault() to stop the browser from scrolling the page, selecting text, or firing a synthetic click when the player is really trying to play.
While watching the videos below, pay attention to three things: which element the listener is attached to, which event properties carry the information you need, and how the handler avoids doing too much work on its own. Mouse and touch coordinates in particular are reported relative to the viewport, so note any step that converts them into canvas coordinates — that conversion is something you will need in your own project.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A game is really just a data structure that changes over time. Behind the sprites and animation sits a game state: the score, the number of lives remaining, the positions and velocities of every entity, and a flag telling you whether the game is running, paused, won, or lost. Every frame of your game loop reads that state, updates it according to the rules, and redraws the screen to match. If the state is clean and well organized, the rest of the game becomes much easier to write, test, and debug.
In this topic you will work through the mechanics that drive those state changes. Collision detection answers the question "did these two things touch?" and usually drives everything else: a hit may increase the score, remove an entity, deduct a life, or end the round. Win and loss conditions are checks you run during the update phase, and restarting the game is simply resetting your state object back to its initial values rather than reloading the page. Keeping all of this in the update phase of one unified loop prevents the scattered, hard-to-trace bugs that come from changing state in random event handlers.
As you watch, pay attention to two things. First, the geometry and logic of rectangle overlap tests: how the comparison is built, and where in the loop it belongs. Second, the broader idea of state that the React videos illustrate: what belongs in state versus what is passed in, why state updates may not take effect immediately, and why you should treat state as something you replace rather than quietly mutate. Those habits transfer directly to a plain JavaScript Canvas game even though the framework differs.
The first installment of a mini-series on 2D collisions in JavaScript game development, focused on axis-aligned rectangle (bounding box) collision detection. Expect a walkthrough of the overlap comparisons between two rectangles using their x, y, width, and height, and how to call that test from game code. As the opening part of a series, it establishes the basic case that later, more complex collision scenarios build upon.
Rectangle overlap testing is the workhorse collision technique for browser games, and this video targets it directly in a short, practical, game-development context that matches the Collision Detection subtopic.
A short conceptual video contrasting state and props in React, explaining which data an object owns and manages itself versus which data is handed to it from outside. It covers how changing state triggers a re-render and why props should be treated as read-only.
The distinction maps cleanly onto game design: your score, lives, and status flags are owned state, while entity configuration is more like props, which helps you plan the overall state structure before coding.
This video explains that setState in React is asynchronous and does not immediately reflect the new value, and demonstrates the problems that arise when you read state right after setting it. It typically shows the callback or updater-function pattern for computing a new value from the previous one.
It teaches the discipline of deriving new state from the previous state rather than assuming an immediate update, a habit that prevents subtle scoring and lives-counter bugs when several events fire within a single frame.
Together these videos support the planning and logic outcomes of the module. The two state-focused videos reinforce MO1 by pushing you to decide what belongs in your game's state structure and how it should be updated safely, which also underpins the clean restart and reset behavior you need for a finished project (MO5). The rectangle collision video speaks directly to MO4, giving you the overlap test that triggers scoring, life loss, and win or loss transitions inside the update phase of the loop you build for MO2. None of the videos cover input wiring (MO3) or requestAnimationFrame directly, so rely on the module readings and your own lab work for those pieces and use these videos for the logic and state layer.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Up to this point you have practiced the pieces of browser game development separately: drawing shapes and images on a Canvas, animating them frame by frame, capturing keyboard and mouse input, and writing the logic that decides what happens next. This topic is about assembly — taking those separate skills and fitting them into one project with a sensible file structure, a single authoritative game loop, and clear rules for when the player wins or loses.
Assembly is where most beginner projects break down, because subsystems that worked in isolation start competing: input events fire at unpredictable times, drawing code is scattered across functions, and state is updated in two places at once. The discipline you are learning here is to keep one loop that clears, updates, and redraws every frame; to let event handlers only record intent rather than directly move objects; and to keep game state in one structure that logic and rendering both read from.
As you watch the videos below, pay less attention to the specific game being built and more to the architecture. Ask yourself: where does this project store its state? What happens exactly once per frame versus once per event? Where do collision checks and scoring live? How does the developer get the finished game onto a page so someone else can play it? Those questions map directly onto the subtopics in this module.
A fast, complete walkthrough of building a slingshot shooting game in JavaScript using the matter.js 2D physics engine, with source code provided. Based on the title and description, it covers setting up a project, creating a world of game bodies, handling mouse-based player input to aim and fire, and running the simulation and rendering loop that keeps everything moving. The compressed ten-minute format means you see the whole pipeline from blank page to playable game in one pass.
It is a useful end-to-end model of assembling a complete project rather than an isolated technique, and the mouse-driven slingshot interaction is a clear example of wiring player input into game state. The available source code lets you compare your own project structure against a working one.
A build-along tutorial that recreates the classic Space Invaders arcade game in JavaScript. A project like this typically involves drawing player and enemy entities, animating enemy movement each frame, reading keyboard input for movement and firing, detecting collisions between projectiles and targets, and tracking score along with win and lose conditions. The short runtime suggests a brisk, code-focused presentation you may want to pause and follow along with.
Space Invaders exercises nearly every subtopic in this module at once — drawing, animation, keyboard input, collision detection, scoring, and game-over logic — making it a strong template for your own integrated project.
An official Chrome for Developers overview of recent additions and improvements to the Canvas2D API. Expect a tour of newer drawing and context features, performance-related capabilities, and guidance on what the modern 2D rendering surface can do beyond the basics you have already used. It is explanatory rather than a step-by-step build.
It comes directly from the browser vendor, so it is an authoritative reference on the rendering layer your finished game depends on, and it helps you make informed choices while combining your drawing and animation systems and testing the result across browsers.
The two build-along projects show complete games assembled from drawing, animation, input, and logic, which is the core of MO5, and both demonstrate the single update-and-redraw loop pattern behind MO2. Their mouse-based aiming and keyboard-based movement illustrate the input wiring described in MO3, while the shooting and collision mechanics model the collision detection, scoring, and win/loss transitions in MO4. Watching each project take shape from an initial concept also reinforces MO1, since you can see how the designer's choices about entities, rules, and state structure shape the code. The Canvas2D update video supports the rendering foundation for MO2 and MO5, and gives you an authoritative reference point when debugging or presenting your finished game.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.