Sprig is a game console you have to earn by shipping a game

The hardware is a reward, not a prerequisite

Sprig is described as a game console where every user is a creator, and the constraint that shapes the whole project is stated early. It can only be obtained by building a tile-based game in the web-based game editor and shipping it in the community gallery.

So the device is not sold and not given to anyone who asks. The sequence is spelled out as a loop.

Make a game, share it with the community, receive your device, play Sprig games on it, hack on the device for more projects.

And the audience rule is explicit. Only teenagers and younger can receive Sprigs, while all are welcome to submit to the gallery.

That is an unusual design for an open source hardware project, and it comes from the mission of Hack Club, a community of teenage hackers. The incentive is a physical object, which is exactly the thing a learning environment needs in order to make a beginner care, and the entry price is a published artefact rather than a purchase.

The design intent for the editor follows from the same logic. The goal is to take learning to code from studying language syntax to making small creative projects, and the Sprig game engine exposes a small construction kit for making tile-based games, a kit that helps you focus on being creative instead of learning big APIs.

The philosophy section names the educational tradition it comes from. People learn best when they make things that they care about, which they can then share with others, and that learning philosophy is called constructionism, and Sprig is a type of microworld, an environment where you can discover programming by using it to express yourself.

The same JavaScript runs on a desktop and a four dollar microcontroller

The technical claim is in the README and it is the interesting engineering problem in the project.

The games are just JavaScript, and the project built a custom system to run that same JavaScript on the microcontroller. The README says they did some fun engineering to get Sprig to work and to make their games run the same on your desktop computer and a $4 microcontroller, and that this involved custom JS runtimes with optimizations in C and even PIO assembly.

PIO is the programmable I/O block on the RP2040, the microcontroller at the heart of the kit, and using it for a JavaScript runtime is about as far from a normal web project as you can get. A JavaScript engine that fits in the memory of a four dollar microcontroller, that draws to a small TFT screen and plays audio through a class D amplifier, is the whole point of the firmware/spade directory.

The repository layout shows the scope of the effort. There is hardware/ for the physical design, engine/ for the game engine, firmware/ with the spade subdirectory for the embedded engine, games/ for published games, and src/ for the Astro site and editor. Then there is a set of directories that are hard to categorise and say a lot about where the project is going: sprig-hax/, which is presumably a modification or jailbreak of the device, yjs-client/ and yjs-signaling-server/ for collaborative editing, font-things/ for font tooling, migration-iframe.html, metrics.ts and scripts/.

The multiplayer pieces are worth a mention because they are the direction of travel. The yjs directories pair a Yjs client with a signalling server, and the package.json includes y-codemirror.next, y-webrtc and yjs itself, so the code editor is wired for collaborative editing, and the Docker compose file runs the client and the signalling server as two separate services.

Astro with Preact Signals, and one leftover Svelte component

The tech stack section is specific enough to be useful, including the admission of the odd one out.

Sprig's editor and site pages are built with Astro, server side rendered through @astrojs/node, using Preact for rendering. The README notes that perhaps somewhat unusually, they predominantly use Preact Signals for state management rather than a component library's own conventions, and the code editor uses CodeMirror.

The signals choice is a real engineering decision rather than a stylistic one. The editor is a single large application surface with a lot of shared state, the game being edited, the assets, the gallery, the auth state, and a signals-based store gives fine grained updates without a virtual DOM diff over the whole tree. The dependencies confirm the shape, with @preact/signals at 2.9.0, preact at 10.29.1 and @astrojs/preact at 5.1.2, and no React or React DOM in the runtime list despite @types/react being present for type definitions from the react-icons package.

And then the admission, there is one legacy Svelte component on the homepage, with svelte at 5.55.8 and @astrojs/svelte at 8.0.4 in the dependency list. A single leftover component in a different framework is the kind of thing that a project usually either commits to or rewrites, and the README is upfront that it is still there.

The rest of the stack is worth listing because it shows the scope of the service rather than just the editor. The database is Firebase, with firebase-admin in the dependencies. Everything pushed to GitHub and all pull requests are automatically deployed on Vercel, with @astrojs/vercel at ^10.0.7. There is @sendgrid/mail for email, bcryptjs for password hashing, a reCAPTCHA key in the environment file, three.js at 0.183.2 and postprocessing for the 3D and visual work, markdown-it for the documentation rendering, and yjs for the collaborative editing. There is also a public LLM API variable, PUBLIC_SPRIG_LLM_API, and a loops API key, which suggests the editor has some assisted features.

The tooling is Bun based, with a bun.lock file, and the test script is vitest run with the iteration and loop time limits set through cross-env.

The container runs the Astro server and health-checks it

The Dockerfile is short and it packages the site rather than the editor, which is a useful detail.

FROM oven/bun:alpine AS build

WORKDIR /app

COPY package.json bun.lock ./
RUN bun install --frozen-lockfile

COPY . .
RUN bun run build

The build stage installs with a frozen lockfile from the bun.lock file, then builds. The production stage copies the dist directory, the games directory, the node_modules and the package.json into a fresh Bun Alpine image. Copying games/ separately is the interesting line, since the gallery of published games is content that has to travel with the deployment.

The server runs on port 4321, the Astro default, with HOST set to 0.0.0.0 so it binds properly inside a container, and there is a health check that polls the /up endpoint every thirty seconds.

HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://127.0.0.1:4321/up || exit 1

CMD ["bun", "run", "dist/server/entry.mjs"]

The command runs the server entry point directly, which is the Astro SSR output, so the image is a Node style server on Bun rather than a static site.

The compose file handles the two collaborative editing services separately, each with its own build context, its own Dockerfile and its own env file, and the ports are exposed rather than fixed, so the host assigns them.

  yjs-client:
    env_file:
      - .env
    build:
      context: ./yjs-client
      dockerfile: Dockerfile
    ports:
      - "3000"

The environment file is the other place where the scope shows. Beyond the Firebase credentials and the reCAPTCHA key, there is an Airtable token and a stuck Airtable base, a Graphite host, which is a metrics backend, a Sendgrid key, a loops API key, a dev code, a public gallery API, a max attempts and lockout duration for auth, and the public GitHub client id, secret and redirect uri for the GitHub login flow.

The hardware kit is the teaching material

The hardware development kit section makes the point that this is not only for gaming.

The Sprig console is designed to be assembled and disassembled, and each kit includes parts needed for getting started with hardware engineering and embedded systems programming. The parts list is given explicitly, and it is a good shopping list for anyone reproducing the build.

It includes a Raspberry Pi Pico, which is the RP2040 microcontroller, a TFT7735 screen, a MAX98357A I2S class D audio amplifier, a whole bunch of buttons, LEDs, a speaker, and a carrier board which wires all these components together while exposing the remaining pins on the microcontroller. The description of the whole is precise, a complete system for generating graphics, sound and handling tactile inputs which is reprogrammable at the touch of a button.

The two details that matter to a buyer are the carrier board and the exposed pins. Most consumer development boards are closed systems, and a carrier board with the remaining GPIO broken out is what turns a game console into something you can attach a sensor to, which is how the device becomes an electronics teaching platform rather than a games machine.

The documentation is in the repository rather than on a separate site, with the assembly guide at docs/ASSEMBLY.md and the hardware designs under hardware/. The README also points at a set of behind-the-scenes documents in docs/ describing the engineering work.

That open hardware is not an accident. The Fully open source section says that shipping a game to the Sprig Gallery is contributing to an open-source project, and that everything about Sprig is transparent and editable, including the hardware designs, the game engine, the embedded game engine for the RP2040 chip, and the editor and website itself.

Where Sprig is the wrong tool

The first wrong case is an adult who wants the console. Only teenagers and younger can receive Sprigs. Everyone can submit to the gallery and everyone can use the editor, but the hardware is the incentive and it is restricted by age. That is the design and it is not a bug, but it does mean the hardware path is closed to a lot of people who would otherwise be interested.

The second wrong case is a professional game developer looking for an engine. The construction kit is deliberately small, tile based, and aimed at a beginner, and the same JavaScript runs on a four dollar microcontroller. A team shipping a real game wants an engine with a scene graph, an asset pipeline, an editor with an inspector and a console, and a lot of the surrounding infrastructure that Sprig leaves out on purpose.

The third wrong case is a production deployment of the editor itself. The service depends on Firebase, Vercel, Sendgrid, Airtable, Graphite, reCAPTCHA, a GitHub OAuth flow, and a bunch of API keys from the environment file. It is a community service run by Hack Club, not a product with a documented configuration surface, and the security and support model of a hobby project run by a youth organisation is not what a company would put in front of users.

The fourth wrong case is expecting a stable release cadence. The tagged releases are v2024.35 from 2024-08-30, v2024.36 from 2024-09-05 and v2024.38.01 from 2024-09-18, and the package.json version is 1.0.0, which tells you the version is not tracking releases in any meaningful way. The last push to main was on 2026-10-15, so the work continues, but the tags have not moved in two years and the deploy is continuous from the branch rather than from a release.

How it differs from a generic web game editor

The comparison worth making is with the many browser game editors and learning platforms that exist, and the difference is that Sprig's editor has a hardware destination.

A typical web editor teaches by giving you a canvas, a set of APIs and a sandbox. You write code, it runs in the browser, and that is the end of the loop. Sprig's editor has the same shape, a construction kit with a small API for tile-based games, but the output of the loop is a physical object in your hand that runs the same code.

That difference changes several things at once. It makes the motivation real, since a teenager who can hold the result of their work is motivated in a way that a browser canvas is not. It makes the API small on purpose, because the alternative is a runtime that will not fit on a microcontroller, and the constraint produces the teaching. And it makes the community legible, since every game in the gallery is something you can open, read and fork, and the README says games are designed to be shared and hacked on with friends.

The second difference is the open hardware. Most learning platforms are software only, and even the ones that ship kits ship them as opaque products. Sprig publishes the carrier board design, and the README's point about assembling and disassembling is that the device is a platform rather than an appliance.

The third difference is where the effort goes. The interesting engineering is not in the editor, which is Astro and CodeMirror, but in the runtime, the custom JavaScript engines with C optimisations and PIO assembly that make the same code run on a desktop and on the RP2040. A platform that ships a hardware target has to keep two environments in step, and that constraint is what makes the project interesting to an engineer and not only to a beginner.

Editorial conclusion

Sprig fits a teenage programmer who wants a physical device to program and a community of peers, and it fits an educator looking for a hardware and software package where the hardware kit teaches soldering and embedded work alongside a JavaScript intro. It does not fit an adult who wants the console, because the devices go to teenagers and younger only, and it does not fit a professional game developer, since the construction kit is deliberately small. Before building a kit, read the assembly documentation and note the parts list, a Raspberry Pi Pico, a TFT7735 screen, a MAX98357A I2S class D amplifier, buttons, LEDs, a speaker and a carrier board, and note that the newest tagged release is v2024.38.01 from 2024-09-18 with the last push on 2026-10-15.

Frequently asked questions

Official sources

1. hackclub/sprig on GitHub
2. License: MIT
3. Project website
4. README
5. Releases