Game development has its own vocabulary. Some terms come from graphics programming, some from game design theory, some from decades of shared convention across the industry. When you read a tutorial or watch a talk and encounter an unfamiliar word, the answer is usually simpler than the jargon suggests. This glossary covers the terms you will most often encounter when building games with Three.js, Vite, or any browser-based stack.
Terms are grouped roughly by category — engine concepts, design concepts, and technical terms — with plain descriptions that prioritize understanding over precision.
The heartbeat of every real-time game. A function that runs continuously — typically 60 times per second — and in each iteration reads player input, updates the positions and states of every game object, checks for collisions, and renders the current frame to the screen. Everything in a running game happens inside this loop. In browser games, the standard way to run it is requestAnimationFrame(), which ties the loop to the browser's repaint cycle and automatically pauses when the tab is not visible.
Also called: update loop, render loop, tick
The amount of time that has passed since the last frame was rendered, measured in seconds. A fast machine might render a frame in 8ms (delta = 0.008); a slow one might take 33ms (delta = 0.033). Without delta time, a game running at 120fps would move everything twice as fast as the same game at 60fps. By multiplying all movement values by delta time, movement speed becomes independent of frame rate — the game behaves the same on any hardware. In Three.js, THREE.Clock.getDelta() provides this value.
Also called: dt, time step, frame time
A hierarchical tree structure that describes all the objects in a 3D scene and their relationships to each other. In Three.js, the Scene object is the root of the graph. Every mesh, light, and camera you add to the scene becomes a node in that tree. Child objects inherit the transformations of their parent — if you move a parent object, all its children move with it. This makes it easy to build complex objects out of simpler parts: a car with four wheels that all move when the car moves, or a player character with a weapon attached to their hand.
The system responsible for translating the mathematical description of a 3D scene — object positions, materials, lights — into pixels on screen. In web games, the renderer talks directly to the GPU through WebGL, a JavaScript API that lets browsers draw hardware-accelerated 3D graphics. Three.js wraps WebGL in a much friendlier interface so you describe what you want rendered rather than writing low-level GPU instructions. The renderer is typically initialized once and its output is drawn to an HTML <canvas> element.
How many frames (complete screen updates) are rendered per second. 60fps is the standard target for smooth gameplay because it matches the refresh rate of most displays. Below 30fps, motion starts to look choppy and controls feel unresponsive. Games should be designed to be frame-rate independent using delta time rather than assuming a fixed frame rate. Some monitors run at 120hz or 144hz — games that multiply movement by a fixed value per frame will run too fast on these displays without delta time correction.
FPS = Frames Per Second
A performance technique where game objects are pre-created and reused rather than created and destroyed repeatedly. Creating a new 3D object (allocating memory, initializing geometry, registering with the scene) is expensive. Destroying one triggers garbage collection. In a game that spawns dozens of bullets or enemies per second, constantly creating and destroying objects causes frame rate stutters. Object pooling solves this by maintaining a list of inactive objects that are recycled — moved back into position and reactivated — when needed. Relevant once your game spawns many objects at high frequency.
The collection of visual and audio feedback effects that make a game feel alive and satisfying to interact with. Coined by game designers Martin Jonasson and Petri Purho, "juice" describes everything that happens in response to player actions that goes beyond bare mechanics: the screen shake when something explodes, the satisfying sound when collecting a coin, the flash of color when an enemy is hit, the squash-and-stretch animation when a character jumps. A game with identical mechanics but no juice feels broken and cold. The same game with good juice feels polished and rewarding. Adding juice is almost always the highest-return improvement you can make to a working prototype.
Also called: game feel, polish, feedback
The fundamental repeated action cycle that defines what a game is. For a dodge game, the core loop is: move, avoid enemies, survive. For a platformer: jump, land, progress. Every other system in the game exists to support, extend, or reward this loop. When designing a game, identifying and protecting the core loop is the most important decision you make — it determines whether the game has a clear identity. A game with a fuzzy or broken core loop cannot be saved by additional features. A game with a tight, satisfying core loop can succeed with very little else.
The pace at which a game increases in challenge over time. A good difficulty curve starts accessible enough for new players to grasp the mechanics, then scales up gradually to keep experienced players engaged. In arcade games, difficulty curves are often driven by a single parameter — spawn rate, enemy speed, obstacle density — rather than by explicit difficulty levels. This simplicity produces emergent challenge: the game gets harder naturally without complex difficulty management logic. The most common mistake is making early difficulty too high (players quit before learning) or too gradual (experienced players lose interest).
A design property that communicates to the player what something does or how to interact with it, without requiring instruction. A glowing gold orb in a dark game communicates "collect me" without a tutorial popup. A bright red enemy communicates "danger" before any collision occurs. Good game design uses visual language — shape, color, animation, sound — to make the game's rules legible to the player through experience rather than text. When players say a game felt "intuitive," they mean the affordances were well-designed. When they say they "didn't know what to do," the affordances were absent or contradictory.
The quality that makes a player want to start the game again after finishing or losing. In arcade-style games, replayability typically comes from score competition (beating your own best or a global leaderboard), mastery progression (getting better at a skill-based mechanic), procedural variation (levels or obstacles that are different each run), or the pure satisfaction of the core loop. Replayability is different from length — a 2-minute game with high replayability is more engaging than a 20-hour game you play once. For microgames in particular, replayability is the primary metric of success.
The invisible geometric shape used for collision detection, which is usually simpler than the visible shape of the object. A character sprite might look like a complex human figure, but its hitbox might be a simple rectangle or capsule. Using simpler shapes for collision calculations is faster for the CPU and, importantly, often more forgiving for the player — a hitbox that is slightly smaller than the visible object means players perceive "near misses" as genuine skill, which feels fair and satisfying. Overly large hitboxes that match complex geometry feel punishing and unfair even when technically correct.
Also called: collider, bounding box, collision volume
The process of determining whether two game objects are occupying the same space — whether they have "collided." There are several common approaches. AABB (Axis-Aligned Bounding Box) checks whether two rectangles or boxes overlap, using simple min/max comparisons on X and Y (or X, Y, Z) coordinates. Circle/sphere collision checks whether the distance between two object centers is less than the sum of their radii — a single distance calculation. These simple methods are fast and sufficient for most arcade games. Physics engines provide more complex approaches (polygon collision, raycasting, continuous collision detection) for cases where simpler methods fail.
Common methods: AABB, circle overlap, SAT, raycasting
In 3D graphics, geometry refers to the mathematical description of a shape — the vertices (corner points), edges, and faces that define its surface. A mesh is a geometry combined with a material: the shape plus how it looks (its color, texture, shininess, etc.). In Three.js, you create a mesh by combining a Geometry object (like BoxGeometry or SphereGeometry) with a Material (like MeshStandardMaterial). The geometry defines the form; the material defines the appearance. Both are separate objects intentionally — the same geometry can be shared across many meshes with different materials.
A JavaScript API that gives browsers access to the GPU for hardware-accelerated graphics. WebGL is based on OpenGL ES and operates at a low level — you write shader programs in GLSL (a C-like language) that run directly on the graphics card. Writing raw WebGL requires managing buffers, uniforms, attributes, and shader compilation by hand, which is powerful but verbose. Three.js is an abstraction layer over WebGL that lets you describe what you want rendered (meshes, lights, cameras) rather than writing the underlying GPU instructions. For most browser game development, you never need to touch WebGL directly.
A small program that runs on the GPU to determine how pixels are drawn on screen. There are two main types: vertex shaders (which determine where each point of a 3D object ends up on the 2D screen) and fragment shaders (which determine the color of each pixel). Shaders are written in GLSL and run in parallel across thousands of GPU cores, which is why GPUs can process millions of pixels per frame far faster than a CPU ever could. Three.js writes the necessary shaders for you when you use its standard materials. Custom shaders using ShaderMaterial are for advanced visual effects beyond what built-in materials provide.
A mathematical function that smoothly transitions a value from one point to another over time. lerp(a, b, t) returns a value between a and b, where t is a number from 0 to 1. At t=0 the result is a; at t=1 it is b; at t=0.5 it is halfway between. In games, lerp is used constantly for smooth camera movement (gradually tracking toward the player position), animated transitions between states, fading effects, and any time you want a value to move toward a target smoothly rather than snapping instantly. The formula is simply: a + (b - a) * t.
A technique for making animations feel more natural by varying the speed of a transition rather than keeping it linear. A linearly interpolated movement starts and ends at the same speed, which feels mechanical. Ease-in starts slow and accelerates; ease-out starts fast and decelerates; ease-in-out does both. These mimic how real objects move — a thrown ball accelerates as it falls, decelerates as it rises. CSS transitions have built-in easing functions. In game code, easing curves are usually implemented as mathematical functions applied to the interpolation factor. Common choices: quadratic, cubic, sine, and exponential easing.
A development tool that takes your source files (multiple JavaScript modules, CSS, images) and combines them into optimized files for deployment. When you write a game with ten separate JavaScript files and use ES module imports, browsers can technically load them individually — but this results in ten separate network requests and no optimization. A bundler like Vite or Webpack processes all those files, resolves the imports, removes dead code (tree shaking), minifies the output, and produces one or a few optimized files. The result loads faster in production and exposes less of your source code structure. Vite is the standard choice for new Three.js projects in 2024-2026.
Common bundlers: Vite, Webpack, esbuild, Rollup, Parcel
A development feature that updates changed code in the browser instantly, without a full page reload, and without losing the current state of the application. When you change a CSS file, HMR updates the styles immediately while the game keeps running. When you change a JavaScript module, HMR swaps the module in memory. This dramatically speeds up the development cycle for visual work — tweaking a color, adjusting a movement value, or repositioning an element gives immediate visual feedback. Vite provides HMR out of the box. Without HMR, every code change requires manually refreshing the page and navigating back to the state you were testing.
Abbreviation: HMR
A Content Delivery Network is a geographically distributed system of servers that serves static files (HTML, CSS, JavaScript, images) from a location close to the user requesting them. Instead of all traffic going to a single server in one city, a CDN has nodes in dozens of cities worldwide. A player in Tokyo gets the game files from a Tokyo CDN node rather than a server in New York, which means much faster initial load times. Netlify deploys your game to its global CDN automatically — your deployment command is simply a git push, and the rest is handled. CDNs also absorb traffic spikes; if your game goes viral, a CDN handles the load without your server going down.
CDN = Content Delivery Network
HTTPS is the secure version of HTTP, the protocol used to transfer web pages. The S stands for Secure — communication between the browser and server is encrypted using SSL/TLS certificates, preventing third parties from reading or modifying the data in transit. For games specifically, HTTPS matters because modern browsers block many APIs (including some audio and geolocation features) on non-HTTPS pages. It also affects trust: browsers show a padlock icon for HTTPS sites and warn users about HTTP sites. Netlify provisions free SSL certificates automatically via Let's Encrypt, so any game deployed there is HTTPS by default with no configuration needed.
SSL = Secure Sockets Layer · TLS = Transport Layer Security
→Keep Building
Understanding the vocabulary is step one. The tutorials on this site walk through applying these concepts in working code — from the first Three.js scene to a deployed game with a global leaderboard. If a term in any tutorial sends you back here, that means the glossary is doing its job.
Game development is a discipline where the best way to learn the vocabulary is to encounter it in context while building something real. The definitions above will make more sense after you have written your first game loop, debugged your first collision detection, and watched a lerp-driven camera track a player for the first time.