What I’m trying to optimize for is the “tight loop” that made older machines fun: code a little, run immediately, discover weird edges, and lean into the constraints instead of fighting them.
Play (includes sample games): https://beep8.org
SDK + documentation: https://github.com/beep8/beep8-sdk
A few deeper details / design goals:
Browser-first runtime: share a link and anyone can try your game immediately, without downloads or installers.
C/C++-first dev workflow: write actual C/C++ (not a scripting language), compile with the provided toolchain, and ship a small build artifact.
Deliberate constraints: limited palette and a compact screen resolution, plus a simple graphics model intended to encourage “stylized” solutions rather than brute force.
Two API layers: a low-level graphics layer for people who want control, and a PICO-8-like convenience layer for fast prototyping (so beginners aren’t forced to start at the metal).
Built for tiny games and prototypes: short sessions, one-button/touch-friendly input patterns, quick iteration, and easy sharing.
What I’d love feedback on:
Developer experience: is the SDK setup smooth? what’s confusing? what would you change in the “first 30 minutes” experience?
Performance + feel: does it run smoothly on your machine/browser? any jank, long startup, or input latency?
Constraints: which ones feel creatively “fun,” and which ones feel like pointless friction?
APIs: are the names/shapes discoverable? do the examples teach the right mental model?
Missing pieces: what’s the first thing you’d want added (tools, docs, examples, debugging, asset pipeline)?
If you try it and have blunt criticism, please don’t hold back. I’d rather hear “this is annoying / unclear / pointless” than polite silence.