A sprite is a small two-dimensional picture that a display system draws on top of a background, independently of the rest of the screen, so that it can be moved, animated, and tested for collisions without redrawing everything behind it. On the machines of the late 1970s and early 1980s the idea was implemented directly in silicon: a dedicated video chip stored a handful of small bitmaps and a few position registers, and the hardware overlaid those images on the raster scan as the picture was generated. This let underpowered processors produce smooth, flicker-free motion that would have been far too expensive to compute pixel by pixel for the whole frame.
Different manufacturers used different names for the same concept. Commodore’s documentation called them “Movable Object Blocks,” abbreviated MOB, while marketing and most programmers used the friendlier word “sprite.” The Commodore 64 Programmer’s Reference Guide, published by Commodore Business Machines in 1982, devotes a full chapter to them, describing sprites as graphics objects that “can be programmed to move independently on the screen” and explaining how the VIC-II video chip supports eight of them at once, each a 24-by-21 grid of pixels with its own color, position, and display priority so that shapes can pass in front of or behind one another.
The deeper idea, separating a movable on-screen symbol from the static background, reaches back to the very first interactive television displays. Ralph Baer’s foundational patent US 3,728,480, “Television Gaming and Training Apparatus” (filed 1971, granted 1973 and assigned to Sanders Associates), describes generating a controllable “symbol, such as a rectangle, bar, dot or a pair of dots” that the player moves around the screen relative to a separate background image. That movable spot is the conceptual ancestor of the sprite: a distinct graphical object the hardware tracks and positions on its own.
Sprite hardware shaped the look of a whole era of games. Player characters, enemies, bullets, and the bouncing ball of a paddle game were all sprites, and the limits of the hardware, such as the number of sprites visible on a single scan line, became design constraints that programmers learned to exploit through tricks like raster interrupts to reuse the same sprite many times down the screen. As CPUs and memory grew cheaper, software-composited sprites drawn into a framebuffer replaced dedicated chips, but the term and the technique persist in 2D game engines to this day.
The sprite is a good example of how a hardware shortcut became a durable abstraction. It began as a way to dodge the cost of full-screen redraws, and it survived long after that cost disappeared because it matched how people think about games: a cast of independent objects moving over a scene.