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.