BUILD STUDIO / GAME ENGINEERING
Orbit Run
A playable loop you can explain
Repair an editable Canvas game while keeping input, simulation, rendering, audio and local persistence separate.
Browser smoke tests execute your pure game/save modules in a disposable, network-restricted worker. Play the complete edited game using its downloaded local server. Canvas input, audio and origin-local saves are tested separately from pure simulation.
Opening your workspace…
The small project source is loaded only when this workspace opens.
Original project brief and legacy stage notes
Cross-academy build · 6 substantial stages
Ship a complete browser game
Build a small synthetic arena game with a reliable loop, accessible input, collision, audio, saves and a credible leaderboard architecture. Keep the game playable without accounts or cloud services.
This is a project brief and local evidence notebook. Implement the project in your own development repository using synthetic data. Checklists and the review question record self-review; LearnLab does not execute these project files, inspect a live database, grade the implementation or certify security. Starter snippets are deliberately partial. Link actual commands, outputs, revisions and screenshots to your notes. Publishing requires a separate deliberate release decision.
Skills this project brings together
- Give every resource an owner
- The stack must empty before queued work runs
- A game is state evolving through time
- Actions outlive individual input devices
- Movement is a vector; collision is a query
- State machines make behavior explainable
- Turn a difficult playtest into a reproducible experiment
- Audio is a resource graph with a lifecycle
- A save is untrusted, versioned input
- Optimize the frame you can measure
- Choose the test that can actually prove the claim
Implementation stage · self-review
1. Separate time, state, update and render
Make a player collect beacons while avoiding a moving obstacle. Keep update logic independent of Canvas drawing. Specify whether you use a bounded variable step or a fixed-step accumulator, and what happens after a background-tab pause.
Acceptance criteria
Mark an item only after you have reviewed the corresponding implementation and evidence. These are your declarations, not automated test results.
Concrete tests to run
- With no collision, speed 120 units/second moves approximately 120 units over one second at both 60 and 120 updates within a stated numeric tolerance.
- A paused update leaves position, score and elapsed gameplay time unchanged.
- Starting/restarting five times still creates one active loop.
- A simulated five-second scheduling gap follows the documented catch-up policy rather than teleporting through the arena.
If a 120Hz display makes the game run twice as fast, inspect units and the update contract before changing rendering quality.
Open the partial starter
function integrate(position, velocity, dtSeconds) {
return { x: position.x + velocity.x * dtSeconds, y: position.y + velocity.y * dtSeconds };
}
// Keep collision and rendering outside this deliberately small calculation.This fragment frames the next design decision. It is not a finished implementation.
Your evidence notebook
This notebook stores text and review declarations. It does not execute files, grade a capstone, grant mastery, or publish an application. Up to 50 recent learning drafts are retained; export a backup for longer-term work.