◓ Sprite

§0 The thesis

hoop already has NPCs. The econ kernel breeds whole societies from a seed — people who "wear many hats" (Jim = mend@chopshop + grow@home + worship), each bound to a stable chamber-address slot (chunk, ordinal) in the deterministic ship engine. What it does not have is a way to look at one of them. Today an NPC is an abstract glyph. This wing closes that gap: it turns a social genome into a picture.

The house method is to devour the world, then pare back — the same arc as fable's wings, the read/ apparatus, and the borges engine. So this document first takes the broadest possible view of what a sprite is, what it is made of, and what limits it; then it collapses that whole space onto the single, sharply-constrained application: an NPC in hoop. The three questions the brief asked — what is a sprite, what are its components, what are its constraints — are answered in Parts I–III at full breadth, and re-answered for our case in Part IV.

§I What is a sprite? — devour

A sprite is a two-dimensional image — historically a bitmap — that is composited into a larger scene as an independent, movable object, most often in a 2D game. It floats on top of the background without overwriting it. That "floating" is the etymology: the term was coined around 1979 by Dave Ackley at Texas Instruments for the TMS9918 video display processor, because the figures hover over the backdrop "like a ghost or mythological sprite."

The hardware → software arc (why the word means two things)

Originally a sprite was a hardware trick, not an image format. Early consoles and home computers had no full-screen framebuffer to spare. Instead, dedicated video hardware composited a handful of small bitmaps per scanline, on the fly, as the CRT beam swept — no CPU, no backing buffer. The TMS9918 (1979) gave the TI-99/4 up to 32 sprites of 8×8 or 16×16 px; the same idea shows up in the Atari VCS (1977), Commodore 64 (1982), NES/Famicom (1983), Genesis, MSX, Amiga.

As machines got framebuffers and fill rate to burn, the optimization stopped mattering and the word migrated to the image itself: today a "sprite" is just a 2D image (and its animation frames) drawn into a scene, whether by GPU, by canvas drawImage, or by a game engine's sprite batcher. Both senses are alive — and, crucially for us, the old hardware sense is a ready-made generative grammar (see §III): its limits are exactly the kind of tight rules that make procedural output cohere.

A taxonomy (the whole world, before we cut)

§II Components — the anatomy of a sprite

Pull any sprite apart and you find the same organs. This is the full parts list; Part IV keeps only the ones an NPC needs.

§III Constraints — the limits (and why we want them)

Historical hardware limits — a found grammar

The classic machines were brutally constrained, and those constraints are famous precisely because they shaped a coherent look:

• NES: 64 sprites total, but only 8 per scanline (the 9th vanished — the source of 1980s sprite flicker). Each 8×8 tile drew from a 3-colour palette + 1 transparency. Big characters were faked by tiling several sprites (metasprites).
• Commodore 64: 8 hardware sprites, multiplexed by racing the beam to show more; a fixed cycle budget per scanline (64 NTSC / 63 PAL).
• TMS9918: 32 sprites, 8×8 or 16×16, with similar per-line ceilings.

These aren't just trivia. A limited palette, a small grid, a transparency key, and mirror-symmetry are exactly the rules that make random output read as a believable character instead of noise. The retro constraints are our procedural cohesion engine — we adopt them on purpose, not for nostalgia.

Modern limits

• Atlasing & draw calls: pack into one texture; each material/texture switch is a GPU draw call. Batch or pay.
• Power-of-two & fill rate / memory: texture dimensions, overdraw, mipmaps.
• Readability: at small on-screen size the silhouette carries the meaning; a limited palette (16–64 colours) keeps it legible.

Our constraints — the pare-back (these are non-negotiable)

§IV Pare back — the application: hoop's people

Now collapse the whole space onto one job. A hoop NPC is not decoration; it is a reading of the social genome. The econ kernel already gives every person a structure — we just need the sprite to express it.

Where NPCs come from (already built, in hoop/econ/)

• A genome breeds a town from a seed: a role mix, building footprints, household and affiliation propensities, an archetype (balanced · dormitory · company · commons).
• People wear hats — a multiplex of verb@place affiliations (mend@chopshop, grow@home, worship). Their hats say where they walk; the "desire-line roads" are literally the Laplace transform of that NPC motion.
• Each is slot-bound via postal.js to a stable (chunk, ordinal) chamber address.

What the sprite must express

The mapping is the design. The sprite's parts and palette are functions of the genome:

The win condition: you glance at a street in hoop and can read the economy off the crowd — clusters of like-dressed workers near the chopshop, mixed dress in the commons — without a single label. The sprite layer makes the econ genome legible at a glance.

§V The engine — genome → sprite

A pure, deterministic pipeline mirroring ship.js / the econ genome / borges' generator. Five stages, each a pure function of the one seed:

1. Seed. Hash the NPC's gid (chamber address) to a 32-bit seed with the house PRNG (xmur3 → mulberry32, as in borges/js/prng.js). All later randomness draws from this one stream — determinism by construction.
2. Genome. Roll a small parameter bundle: body proportions, the per-material colour ramps (skin / cloth / metal), symmetry axis, and the part selections (head, torso, legs, held-item, head-gear). Where it exists, override rolled genes with the econ society's data (role → item, domain → ramp). This is the "pull" — a genome fully determines a figure.
3. Compose (paper-doll). Stack the indexed-colour parts on the raster grid in z-order, mounting accessories at sockets. Use vertical mirror symmetry for the body so a single seeded half-grid yields a coherent whole — the cheapest path to "this looks like a creature, not noise" (the classic random-sprite technique).
4. Palette. Generate ramps in HSL (a hue per material, a dark→light run), then map indices → RGB. Recolour = swap ramps; pixels untouched.
5. Animate (later stage). Derive — don't author — a small set of clips: an idle bob and a 2–4 frame walk keyed to the NPC's actual motion vector, with an 8-way (mirrored to 4-authored) facing set.

Output forms

• Live draw — the renderer paints directly to hoop's canvas at the @'s position (Stage-0 path; replaces the glyph).
• Baked atlas — for crowds, bake each distinct genome once to an offscreen spritesheet + a metadata sidecar (frame rects, pivots, durations), reused across identical NPCs. The bake is a cache, regenerable from the genome — never the source of truth.
• ATProto record — durability is the genome, not the image: a few bytes that regenerate the figure anywhere. (Lexicon shape is an open question, §Open.)

Determinism contract & tests

Follow the hoop pattern: a pure, zero-dep kernel with a node selftest (sprite.selftest.mjs) asserting same seed → byte-identical pixels, palette ramps monotonic in lightness, and symmetry exact. The kernel must run in plain node (attach to globalThis like borges) so it tests headless; the page only draws what the kernel returns.

§VI Proof of concept — determinism, live

The original Stage-0 sketch, kept here as the doc's worked example: a seeded, vertically-mirrored, ramp-palette pixel figure whose only job is to prove the load-bearing claim — the same seed always yields the same NPC. This grew into the full Sprite Lab (roles, parts, palette archetypes, export); the kernel below is its seed. Click any figure to copy its seed.

§VII Roadmap — devour, then pare

now next later

Stages 1–2 are the kernel and the payoff; everything after is polish. The kernel lives here at mega/sprite/ as a sandbox (the way hoop/paint/ and hoop/econ/ iterate the look before world.js consumes it), then ports into hoop once it's right.

Open questions — decisions to make

References — what we devoured

• Sprite (computer graphics) — definition, the TMS9918 origin, hardware→software arc (Wikipedia).
• Hardware sprites — history — per-scanline composition without a framebuffer.
• Creating NES Graphics & NESdev / SNESdev wiki — 64 sprites / 8 per scanline / 3+1 colour palette, metasprites, flicker.
• C64 sprite workarounds — 8 sprites, multiplexing, per-scanline cycle budget.
• TexturePacker & atlas/pivot/frame metadata — components: atlases, pivots, frame rects, durations, hitboxes.
• Gen Jam 2016: procedurally generating sprites — parts + normalized palettes + recombination + colour ramps.
• Lospec procedural pixel-art generator & Generating Pixel-Art Character Sprites using GANs — symmetry/mirroring, limited palettes, pose generation; the ML frontier (out of scope but noted).