A year ago, Peakylight was my first real attempt at building something from scratch with AI. Since then I’ve used AI to build games for a 128x64 monochrome handheld, a $5 microcontroller, the NES, the Mega Drive, the Nintendo 64, the original PlayStation, the browser and a VR headset.

This post isn’t a list of games. It’s what I learnt climbing that hardware ladder: what each system demands, where the development time actually went, how the build pipelines grew up along the way, and what changed in how I work with AI because of it.

I built them roughly in the order web → Arduboy → ESP32 → N64 → PS1 → Mega Drive → NES. Here they’re ordered by hardware, from the smallest machine up, because that’s the order the lessons make the most sense in.

The Machines at a Glance

Every row taught me something different. The odd thing is that the hardest machines weren’t always the smallest ones.

1. Arduboy: 2.5 KB of RAM and a Lot of Lines

The Arduboy is where I learnt that AI writes code for the machine it imagines, not the one you have. With 2.5 KB of RAM and a 1-bit 128x64 screen, a single careless array is a crash, and float is a luxury you can’t afford.

What I built:

• DownDraft: a 1-bit vertical descent platformer with energy-based jumps, a smash-through “plummet” and EEPROM high scores.
• Stick Fighter: a 10-character fighter using skeletal (bone) animation instead of sprite frames. That’s the only way that many fighters fit.
• Sticks of Rage: the same “Stick Engine” grown into a side-scrolling beat ‘em up with parallax and swarming enemies.
• Ether Echoes: an 8-character, 4-shade grayscale fighter for the Arduboy FX, written in the ABC language.

Ether Echoes: the title card and Kael’s 4-shade stage background.

The Pipelines

I tried three completely different pipelines on the same hardware:

1. Browser IDE. DownDraft was built in Arduboy Cloud, with code, simulator and build output side by side. The build output is the most honest feedback loop on the platform: it tells you exactly how much flash and RAM you have left after every change.

   18,418 of 29,696 bytes of flash and 1,479 of 2,560 bytes of RAM. These numbers matter more than anything the AI says.

2. Desktop twin. Stick Fighter and Sticks of Rage split into Engine, Game and Platform layers, so the same code builds for the Arduboy (arduino-cli) and for desktop SDL2. I also had the AI build a desktop skeletal animation editor to create and export poses.
3. A niche language. Ether Echoes is written in ABC and packaged as main.abc plus a media folder. AI has seen very little ABC, so I was much more involved in that one.

Where the Time Went

Not in the gameplay code. It went into memory and tooling. The skeletal animation system and its editor took far longer than any fighter’s moveset. The SDL desktop build was a huge speed-up, but it also lied to me. On desktop, everything runs at a perfect 60 FPS with endless memory, so it’s easy to blow past the 32 KB flash limit without noticing.

Lesson: a desktop twin is worth it, but flash the real hardware often. The AI only respects a constraint it can see failing.

2. ESP32: Porting a Classic onto a $5 Board

Another World on the ESP32 was my first port rather than an original game. It runs Éric Chahi’s bytecode VM at 50 FPS on a TTGO T-Display, with a custom capacitive touch gamepad PCB and Bluetooth audio.

Pipeline: PlatformIO, LovyanGFX for DMA display transfers, and a pack_assets.py --demo script that downloads the shareware demo and flashes it to SPIFFS. That keeps the repo free of copyrighted data. This was the first project where I wrote a proper AGENTS.md describing the architecture for the AI to follow.

Where the Time Went

• RAM. The original engine wants four 32,000-byte framebuffers (128 KB). With only ~160 KB of free heap, the game’s 65 KB cinematic polygon table failed to allocate, and Lester stood on a black screen. The fix was aliasing down to two physical buffers.
• Hardware gotchas no model would guess. GPIO 12 is an ESP32 strapping pin. Touching that pad at power-on put the board into a boot loop, so the controls had to be re-routed.

Lesson: on real hardware, half the bugs live outside the code. The AI is great at the VM, but someone has to hold the board.

3. NES: 2 KB of RAM and 27,000 Cycles a Frame

Lantern Moth is my newest game, and the closest to the metal: hand-written 6502 assembly on a plain NROM cartridge with no extra chips. You’re a moth flying loops of light around cave creatures to cocoon them, with 15 stages, 3 bosses and 2-player co-op.

The Constraints

Every frame has to fit in about 27,000 CPU cycles. The finished game has 136 bytes of general RAM free and 22 bytes of zero page. The core mechanic, detecting when a trail closes a loop and what’s inside it, is a polygon-fill problem. On a 6502 that means scanline parity with precomputed XOR tables: no flood fill, no stack, and the work spread across several frames so no single frame overruns.

The lighting is all palettes and attribute tables, so it costs no tiles. Moths and cocoons store only their left half and are mirrored. Stage maps are packed at 4 bits a cell.

The Pipeline

This one was the most complete pipeline I’ve had:

• make runs Python asset generators, then ca65/ld65, then usage.py, which prints PRG, RAM and zero-page usage and fails the build if any of them runs short.
• make test runs the ROM headless in jsnes through 134 checks, from clearing all 15 stages by honest loops to co-op revives and zero lag frames.
• make stress flies two moths hard round every stage and reports the worst frame. The worst stress frame came in around 23,900 cycles.
• Mesen with source-level debug symbols for anything the tests can’t see.
• A full release kit: manual, box art, cartridge label and trailer.

Where the Time Went

The frame budget. Getting two moths, crossing trails, team loops and the light rebuild to fit inside one frame took most of the effort, by staggering work across frames, skipping work on busy frames and turning searches into bit tests.

Lesson: the README ends with a “Not verified” section. Sound was never actually listened to, the PAL path is untested, and boss pacing was tuned by scripts rather than by hand. I now ask for that section on every project. Knowing what wasn’t checked is as valuable as the test suite.

4. Mega Drive: Bridget (Coming Soon)

Bridget is a bridge-building physics puzzle for the Sega Mega Drive / Genesis, written in C with SGDK. You build from wood, steel and cable on a budget, then drive vehicles across and watch the Verlet physics decide whether you’re an engineer. It isn’t public yet, but it’s coming soon.

The attract-mode demo running in Mednafen.

The Constraints

The 68000 has no floating point, so the physics core is pure Q16.16 fixed point. It has to produce exactly the same results on NTSC 60 Hz and PAL 50 Hz consoles, or a bridge that holds on one machine collapses on another. There’s no malloc anywhere. Everything is statically allocated, and the README puts the resident footprint under 18 KB of the 64 KB work RAM.

The Pipeline

Bridget was the most planned project. It started with a GAMEPLAN.md, an AGENT.md and a TODOLIST.md of 10 milestones and 100 steps, and the AI worked through them one milestone at a time:

• src/core is portable C with no SGDK includes, so the physics is tested natively with gcc and again under ASan + UBSan.
• The ROM builds with a vendored m68k toolchain, and CI produces a ROM byte-identical to the local build.
• emeshot.py drives Mednafen headlessly, presses buttons and screenshots each screen, so every milestone has visual proof. The screenshots above came from it.

Where the Time Went

Into the physics and determinism. Making a structure behave the same way on both refresh rates is a bigger problem than drawing it.

Lesson: on a fixed-point machine, design the maths first. Splitting the core from the hardware layer is what made it testable at all.

5. Nintendo 64: The One-Day Port

Once the Another World VM worked on the ESP32, the obvious question was “where else can it run?” The N64 port is built with LibDragon inside Docker, packs the game data with DragonFS into the ROM, and a build_rom.sh script pads the binary and signs the CIC-6102 boot checksum. Host-side unit tests check the checksum algorithm and the ROM header.

Where the Time Went

Almost nowhere, and that’s the point. All the commits for this one landed in a single day, because the hard work (the VM, the renderer, the audio mixer) already existed and only the platform layer was new.

Lesson: a clean platform layer pays off twice. The second port is nearly free.

6. PlayStation 1: Bare-Metal Rust and the Biggest Lessons

Both PS1 games are written in #![no_std] Rust and compile to MIPS R3000A machine code with the PSoXide SDK. That means 2 MB of RAM, 1 MB of VRAM, no operating system, and the GTE, MDEC and SPU coprocessors to drive by hand. These two projects were the longest by far: Plattypus has 140 commits over 14 days, and Arduracer PSX has 361 commits over 17 days.

Plattypus

Plattypus is a 3D tactical stealth game about a platypus breaking out of Healesville Sanctuary to get home to his new baby sister. It started on day one as a 2D platformer and was re-imagined as 3D stealth action within hours, which is the kind of pivot AI makes cheap. It has full-motion video cutscenes on the MDEC, a Red Book CD audio soundtrack, and a web player built on my fork of the PSoXide emulator.

Where the time went: the intro video. The FMV played at 6 FPS. The investigation measured each frame at 110 ms of work for a 66.67 ms budget (661%), and it records two diagnoses that turned out to be wrong. One was “the MDEC is backed up”, which was a misread status register. Another was “the decoder can’t run while the CD is reading”, which a six-way probe disproved. Three fixes were built and measured, and none of them reached 15 FPS. What finally worked was changing the codec so each frame needed 5 CD sectors instead of 7. That got it to 148 of 148 frames at 15 FPS.

Arduracer PSX

Arduracer PSX takes my 8-bit ArduRacer FX time-trial racer to 32-bit colour, with 24 circuits, ghosts, AI rivals, car tuning, DualShock rumble and memory card saves.

The pipeline went fully multi-agent. An AGENTS.md sets the rules: every change in its own git worktree, every branch reviewed from four perspectives (architect, systems engineer, game designer, QA) before merging, clippy -D warnings, no panics in game code, and a tools/playtest reference driver that actually drives every circuit. make disc masters a BIN/CUE with CD audio tracks.

Where the time went: finding out what wasn’t real. The audits in that repo were the most humbling part of the year:

• At one point no lap could ever be completed, cars moved ~30x too slowly, and the memory card never saved. Every write panicked.
• Fixed::mul silently wrapped on overflow, so any distance over ~800 units came back as 0.00.
• cargo test on the core crate ran zero tests and exited 0. The CI was green while testing nothing.
• Whole features (force feedback, curb rumble, semi-transparency) were described as done but had no callers.

Plattypus had a similar finding: a test harness that mirrored the game logic instead of testing it. That’s why “tests must exercise the real core crate” is now rule #3 in my AGENTS.md.

Lesson: green isn’t proof. AI is very good at producing things that look finished, like passing CI, sign-off tables and feature lists. On the PS1, the only thing that counted was a measurement or a reference driver actually finishing a lap.

7. Web and VR: Where It All Started

The browser was the easy end of the ladder, and the right place to start:

• Aussie Meme Boss Rush: a neon Three.js boss rush against cybernetic Australian wildlife memes.
• Sun Runner: a low-poly rail shooter diving into the sun.
• Axis Rush: an F-Zero-style racer on a cylindrical track you can flip inside and out of, textured at runtime by my TexGen shader tool. Write-up.

Pipeline: Gemini CLI, a GEMINI.md of project rules, and a single index.html with procedural shaders and Web Audio instead of asset files. One file meant the AI always had the whole game in context, and “deploy” meant pushing to GitHub Pages.

Going VR

Four days after Aussie Meme Boss Rush shipped, it got a WebXR version. It turned out to be far more than a toggle. The desktop game used 2D screen-space hit detection, projecting everything onto the screen and checking where you clicked. In VR there is no screen to click, so targeting had to be rebuilt around controller raycasts from a blaster in each hand. It also gained haptic feedback on each shot and menus rendered onto in-world canvas textures.

Where the time went: debugging. You can’t open devtools inside a headset, so the VR build has its own on-screen debug console and simulated controllers for testing on desktop. Most of the VR commits are some version of “VR fixes”.

Lesson: a new input model means a new game. The rendering ported in an afternoon; the interaction didn’t.

What I Learnt Across Every System

1. Put the budget in the build. The best projects made the constraint impossible to ignore: Arduboy Cloud’s flash and RAM bars, Lantern Moth’s usage.py failing the build, Arduracer’s RAM budget check in CI. An AI respects a number that breaks the build. It doesn’t respect a sentence in a prompt.

2. Measure, don’t guess. AI explanations of performance problems sound authoritative and are often wrong. Plattypus’s FMV investigation went through two confident wrong diagnoses before measurements found the real bottleneck.

3. Green isn’t proof. Tests that run nothing, harnesses that mirror the code, features with no callers. Every bigger project needed a fresh-eyes audit that verified claims by running things.

4. Give the AI eyes. jsnes running Lantern Moth headless, emeshot.py screenshotting Bridget in Mednafen, Arduracer’s playtest driver. The projects improved fastest once the AI could see and play what it had built.

5. Separate the core from the hardware. The same pattern appeared everywhere: SDL plus Arduboy, a pure Rust core crate, Bridget’s src/core, and the Another World VM moving from ESP32 to N64. It makes code testable on a PC, and makes the next port cheap.

6. Write the rules down, and grow them. My agent files went from a few lines of style notes in GEMINI.md to AGENTS.md protocols with worktrees, multi-perspective reviews and banned patterns. Most of the improvement in the later projects came from those files, not from better prompts.

7. Ask for what wasn’t verified. Lantern Moth’s “Not verified” section is now my favourite part of any README.

8. The fun is still my job. Boss pacing tuned by scripts, combos that feel different on a keyboard than on real buttons, a VR game that needed new hands. The AI writes most of the code, but deciding whether it feels right means playing it on the real thing.

Turning the Lessons into an Agents File

Lessons are only useful if the AI actually follows them, and the place for that is the agents file it reads before every session. Here’s the AGENTS.md template I’ve distilled from all of the above. Every rule in it exists because one of these projects needed it.

# AGENTS.md

Read this before changing anything. GAMEPLAN.md says what we're building, TODO.md says
where we are, and this file says how to work.

## 1. The target machine
| Resource | Limit | Current use | Where it's checked |
|---|---|---|---|
| CPU / frame | e.g. ~27,000 cycles (NES NTSC) | | `make stress` |
| RAM | e.g. 2.5 KB / 2 KB / 64 KB / 2 MB | | `make size` |
| ROM / flash | | | `make size` |

- Write code for this machine, not for a PC. If a technique assumes floats, a heap,
  an OS or plenty of memory, it's wrong here until proven otherwise.
- Use fixed point and say the format (e.g. Q16.16). Multiplies must saturate:
  no silent wraparound.
- No dynamic allocation on constrained targets.
- If a change moves any number in this table, update the table in the same commit.

## 2. Budgets live in the build, not in prose
- The build prints resource usage after every compile and FAILS if a budget is exceeded.
- A stress test reports the worst frame. A new worst frame is a regression.
- Never "fix" a budget failure by raising the limit without a written reason.

## 3. Core and platform are separate
- core/ is portable game logic and maths that builds and tests on the host.
- platform/ is display, input, audio and SDK glue. Keep it thin.
- Desktop builds are for fast iteration only. Before calling a feature done,
  check it on real hardware or an accurate emulator.

## 4. Testing
- Tests exercise the REAL core code, never a copy or mirror of it.
- A test command that runs zero tests is a failure. Check the count, not the exit code.
- Give yourself eyes: headless emulator runs, scripted screenshots, a bot that plays.
- Same inputs give the same result on NTSC and PAL. CI builds match local builds.

## 5. Evidence over assertion
- Measure, don't guess. A performance claim needs a measurement and the command
  that produced it. Otherwise label it a hypothesis.
- When a diagnosis turns out wrong, record that. Don't quietly rewrite history.
- Never write a report, sign-off, playtest or hardware result that did not happen.
- A feature is done only when it has a caller, is reachable, and was seen working.

## 6. Always include a "Not verified" section
Every README, PR and milestone summary ends with what was NOT tested and why:
no hardware, no audio output, emulator lacks PAL, tuned by script not by hand.

## 7. Workflow
- One branch or git worktree per change. Never commit directly to main.
- Review from four perspectives before merging: architect, systems/hardware,
  game designer, QA.
- Format, lint (warnings as errors) and test before every commit.
- No panics on shipping code paths. A save that fails must say so.

## 8. Hardware gotchas
- One line per bite, e.g. "ESP32 GPIO 12 is a strapping pin: high at boot means a boot loop."

## 9. The human owns
- Game feel, difficulty and pacing sign-off.
- Real hardware testing, and any claim about it.
- Scope changes and cuts. Propose them; don't make them silently.

Where the rules came from:

• Budgets in the build: Arduboy Cloud’s flash and RAM bars, and Lantern Moth’s usage.py failing the build.
• Core and platform separate: the SDL desktop twin of Stick Fighter, and the Another World VM moving from ESP32 to N64.
• Tests exercise the real code: Plattypus’s harness that mirrored the game, and Arduracer’s cargo test running zero tests.
• Saturating maths: Arduracer’s Fixed::mul wraparound, which turned long distances into 0.00.
• Measure, don’t guess: Plattypus’s two wrong FMV diagnoses.
• Never write a result that didn’t happen: sign-off tables and feature lists that looked finished but weren’t.
• “Not verified”: borrowed straight from Lantern Moth’s README.
• Four-perspective review and worktrees: the Arduracer PSX multi-agent setup.
• Hardware gotchas: the ESP32 strapping pin that no model would have guessed.
• The human owns the fun: every game on this list.

A year ago I wouldn’t have believed I’d ship a PlayStation game in bare-metal Rust or an NES game in 6502 assembly. Bridget is next out of the oven. After that, who knows. Maybe the Saturn?

In 1991, French visionary Éric Chahi released Another World (Out of This World in North America)—a cinematic tour de force that revolutionized video game storytelling. Built entirely on an avant-garde vector polygon engine and a custom 64-thread virtual machine, the game squeezed smooth cinematic cutscenes onto 7.14 MHz Amiga 500 computers with just 512 KB of RAM.

For a long time, I wondered: Could we run the complete Another World engine natively on a bare-metal ESP32 microcontroller with fluid 50 FPS rendering, capacitive touch controls on a custom PCB, and Bluetooth audio streaming?

Here is the story of how anotheresp32 was engineered, the memory and hardware obstacles overcome, and how you can run it on your own board.

The Hardware: LilyGO TTGO T-Display & “TTECH Game Pad”

The project targets the popular LilyGO TTGO T-Display:

• MCU: Espressif ESP32-D0WDQ6 (Dual-Core Xtensa LX6 @ 240 MHz, ~320 KB SRAM, 4 MB Flash)
• Display: 1.14” ST7789 IPS TFT (240x135 pixels, 16-bit RGB565 over high-speed SPI)
• Cost: ~$5–$8

To make it a true standalone portable console, I etched and milled a custom PCB gamepad: the TTECH ESP32 Game Pad.

                        +-------------------+
                        |    [USB-C PORT]   |
                        |                   |
                        |   TTGO T-Display  |
                        |   [240x135 IPS]   |
                        +-------------------+
                              |   |   |
                  +-----------+---+---+-----------+
                  |  TTECH ESP32 Capacitive Pad   |
                  |                               |
                  |       (UP: GPIO 15)           |
                  |             |                 |
                  | (LEFT: 2) --+-- (RIGHT: 13)   |  (ACTION: 27)
                  |             |                 |
                  |      (DOWN: GPIO 32)          |  (JUMP: 33)
                  |                               |
                  |       [START: GPIO 12]        |
                  +-------------------------------+

Instead of using clicky tactile buttons, the board features 7 bare-copper capacitive touch pads connected directly to the ESP32’s internal touch sensor peripherals (Touch 2 through Touch 9).

Technical Obstacle 1: The Boot-Strapping Pin Trap

During PCB design, GPIO 12 was originally routed to DOWN. However, GPIO 12 is MTDI—a critical ESP32 strapping pin that sets the flash voltage regulator to 1.8V if pulled high at power-on! If a player touches the pad or trace resistance pulls GPIO 12 high during boot, the flash voltage drops and the chip enters an unrecoverable boot loop (flash read err, 1000).

The Solution: We remapped the default movement controls strictly to safe, non-strapping pins:

• LEFT: GPIO 2 (Touch 2)
• UP: GPIO 15 (Touch 3)
• RIGHT: GPIO 13 (Touch 4)
• DOWN: GPIO 32 (Touch 9) — Safe!
• ACTION: GPIO 27 (Touch 7)
• TOUCH JUMP: GPIO 33 (Touch 8)
• START / PAUSE (Optional): GPIO 12 (Touch 5)

At boot, the driver executes a 100ms baseline calibration cycle on all 7 channels, computing a resting threshold for instantaneous, jitter-free touch response.

Technical Obstacle 2: The 160 KB SRAM Puzzle & 65 KB Polygon Tables

The native Another World engine renders at 320x200 (4-bit indexed color, 16 colors). Each frame page occupies 32,000 bytes.

The original VM engine relies on 4 visual pages:

• Page 0: Display page (front buffer)
• Page 1: Back buffer (drawing canvas)
• Page 2: Background persistence buffer
• Page 3: Composition / sprite layer

The Problem:

4 x 32,000 bytes = 128,000 bytes (128 KB). On an ESP32 with ~160 KB of free application heap, reserving 128 KB upfront left only ~32 KB of remaining heap. When Part 16001 loaded its 65,156-byte cinematic polygon table (res 25), malloc() failed, leaving Lester standing on a pitch-black screen.

The Engineering Fix:

By analyzing the VM opcode stream, we found that Another World rarely needs 4 distinct physical buffers simultaneously; pages 2 and 3 are largely composition scratchpads. We re-architected the video subsystem to allocate 2 high-speed physical framebuffers (64 KB total) with page aliasing.

This dropped baseline video SRAM consumption from 128 KB to 64 KB, freeing up ~160 KB of contiguous heap. Now, massive 65 KB polygon tables, sound banks, and Amiga audio modules allocate instantly without needing external PSRAM!

Technical Obstacle 3: 50 FPS Vector Polygon Rasterization

Another World does not draw bitmap sprites—it renders dynamic 2D vector polygons grouped in hierarchical transformation trees.

       [Raw Shape Bytecode]
                 │
                 ▼
    [Vertex Transform & Zoom]
                 │
                 ▼
     [Left & Right Edge Walkers]
                 │
                 ▼
    [4-Bit Nibble Packed Scanlines]
                 │
                 ▼ (SPI DMA via LovyanGFX)
    [ST7789 240x135 IPS TFT @ 50 Hz]

To achieve 50 FPS on the ST7789:

1. Integer Fixed-Point Edge Walking: All polygon bounding box calculations and slope interpolations use fixed-point arithmetic.
2. Scanline Nibble Packing: The 4-bit indexed page buffers pack two pixels per byte, allowing fast horizontal word fills.
3. SPI DMA Push via LovyanGFX: Framebuffer updates are converted to 16-bit RGB565 and pushed across hardware SPI at 80 MHz using LovyanGFX’s DMA bus.

The engine supports two scaling modes in hw_config.h:

• Letterbox Mode (Default): Authentic 16:10 aspect ratio (216x135) centered with clean black pillarboxes.
• Stretched Mode: Full 240x135 non-uniform screen stretch.

Technical Obstacle 4: Audio Subsystem (8-Bit DAC & Bluetooth A2DP)

Another World’s iconic audio was composed on Amiga 4-channel MODs and digitized 8-bit PCM samples (thunder cracks, elevator whirs, alien beast growls).

We implemented a dual audio subsystem:

1. Zero-Overhead 8-bit DAC Output (Default):
   • Channels mixed in real-time at 22,050 Hz and streamed via DMA to GPIO 25 (DAC1) and GPIO 26 (DAC2).
2. Wireless Bluetooth A2DP Audio:
   • Mixed audio is upsampled to 44.1 kHz stereo and streamed to Bluetooth speakers or headphones.
   • Includes direct hardware MAC auto-pairing in include/bt_mac.h for instant connection without scan delays.

Technical Obstacle 5: Commercial Asset Policy & 1-Command Demo Loader

A major priority was ensuring the repository remains 100% legal, open-source, and free of DMCA risks. Commercial game banks (bank01–bank0d, memlist.bin) must never be checked into Git.

To give anyone an instant, out-of-the-box playable experience without hunting for floppy disks, we built the --demo auto-fetcher into tools/pack_assets.py:

# 1. Clone the clean C++ engine repo
git clone https://github.com/tonym128/anotheresp32.git
cd anotheresp32

# 2. Automatically download the 1991 public shareware demo archive
python3 tools/pack_assets.py --demo

# 3. Flash SPIFFS filesystem and firmware to ESP32!
pio run -t uploadfs && pio run -t upload

The engine automatically detects whether you’re running the 1991 Shareware Demo (smoothly looping after the wilderness chase) or the Full 13-Level Game (playing all the way to the fortress palace ending).

Source Code & Hardware Details

The entire codebase, circuit diagrams, test suite, and CI workflows are open-source under the MIT License on GitHub:

👉 github.com/tonym128/anotheresp32

Quick Requirements:

• Board: LilyGO TTGO T-Display ESP32
• Toolchain: PlatformIO (VS Code or CLI)
• Assets: Run python3 tools/pack_assets.py --demo or pack your own DOS/Amiga files!

Acknowledgments & Attributions

This project was made possible thanks to the work and reverse-engineering of several pioneers in retro computing:

• Éric Chahi: Original visionary creator, designer, and programmer of Another World / Out of This World (1991, Delphine Software).
• Fabien Sanglard: For his iconic technical book and articles on the engine:
  • Another World Engine Code Review & Architecture Analysis
  • Another-World-Bytecode-Interpreter
• Gregory Montoir (cyxx): Author of rawgl (Another World engine rewrite) and another_js, providing foundational reference for ByteKiller decompression, audio mixer routines, and bytecode dispatch.
  • cyxx/rawgl
• The ScummVM Team: For pioneering retro game engine preservation and Cinematique virtual machine documentation.
• Phil Schatzmann (pschatzmann): Author of ESP32-A2DP, enabling high-performance Bluetooth A2DP audio streaming.
• Lovyan03: Author of LovyanGFX, the ultra-fast SPI DMA graphics driver powering our 50 FPS ST7789 display.

Another World is © Éric Chahi and Delphine Software / Dotemu. This project is an independent open-source virtual machine engine created for retro computing research and preservation.

I built a cross-platform command-line tool and local server that lets you turn prompts into single-page web applications instantly. They run locally, they have automatic Git version control, hot reloading, a built-in state database, and can be easily shared or published.

Take a look at the code - Code or watch the Intro Video

After going deep into AI-driven generation and building things like Peakylight, I realized that the loop of typing prompts into a browser chat window, copy-pasting code into a local file, and refreshing the page was driving me crazy.

So, I decided to build a developer tool to make vibe coding feel truly native.

Special Thanks: A huge thank you to Mr Bob for his beta testing and ideation!

The Problem: The Copy-Paste Loop of Doom

AI models (Gemini, Claude, GPT-4o) are amazing at spitting out complete HTML pages containing CSS, Javascript, and fully functional interactive mockups.

But actually working on them is a drag:

1. You prompt the LLM: “Write me a Pomodoro timer with ambient rain sounds.”
2. It outputs 400 lines of HTML/JS/CSS.
3. You copy it, create index.html, paste it, double-click it. It looks good!
4. You want to make a change: “Add a dark mode toggle and task list.”
5. It outputs another 500 lines. You copy it, select all, paste it, refresh.
6. The styling broke, or a script failed, and now you have no version history to see what changed.

The developer-to-editor feedback loop is broken when you’re writing code through chat windows. There’s no history, no easy local state, and no hot reloading. I wanted to build a “Neuralink” for my local project folder.

The Approach: A Custom Deep Link Protocol & Local Server

I decided to write Promptyly in Go. Why Go? Because I wanted a single, lightweight binary that starts instantly and can handle background servers, custom OS protocols, and git operations without dragging in a heavy runtime.

Here’s how the stack works:

1. The custom prompt:// scheme

Promptyly registers a custom protocol handler with the OS (macOS, Windows, and Linux). Clicking a link like prompt://create?prompt=Sleek+Calculator launches the local promptyly CLI, parses the arguments, and fires up the generation pipeline automatically.

2. Git-Backed Generations

Every app you create is initialized in ~/promptyly-apps/<slug> as a local Git repository. Every time you issue an edit instruction via the CLI terminal, the new code is generated, written to disk, and committed to Git automatically. If the model goes off the rails, you can easily check git diff or rollback.

3. Injected SSE Hot Reloading

We serve all apps concurrently on a single port (6071) at http://localhost:6071/apps/<name>/. The server automatically injects a tiny Server-Sent Events (SSE) listener script into the HTML header. The second the CLI completes an LLM edit, it pings the SSE client, and the page refreshes in the browser instantly.

4. Zero-Config State API

Instead of spinning up a backend (Node, Go, Supabase) for every tiny utility app, Promptyly hosts a built-in JSON database endpoint at _promptyly/api/db that maps to .promptyly/db.json in the app’s folder. The frontend can read and write state simply using standard client-side fetch calls.

5. Local CLI, Remote Serving & Built-in Tunnelling

Promptyly operates as a local CLI communicating with a background service/hosted daemon (running locally on port 6071). For publishing and exploring other developers’ creations, Promptyly connects to a remote registry server hosting a public website on port 6072 (the Sharing Registry). If you want to share a local app with a remote user without publishing it publicly first, Promptyly provides built-in Cloudflare Tunneling to securely expose the local instance via a public URL. The tunneling architecture is modular, meaning it can be easily configured to use alternatives like ngrok or DynDNS.

The Learnings

Building this taught me a few major lessons:

• OS Deep Linking is a Maze: Setting up deep links sounds easy until you try to support macOS (plist associations), Linux (xdg-settings and desktop entries), and Windows (Registry Keys). They all handle parameters differently, and testing the edge cases took a significant chunk of time.
• Local Coding Models are Legit: I built an option to automatically download and run Qwen2.5-Coder-1.5B in llamafile format locally. It runs smoothly on a standard laptop with only 4GB RAM, letting you write and edit apps completely offline without paying for API keys.
• Vibe-first UX matters: Running an interactive terminal prompt loop directly alongside a hot-reloaded browser tab completely changes the experience. It feels like an extension of your own environment rather than a generic chat page.

The Good

• Frictionless Workflow: The speed is incredible. You type .create "sleek expense tracker", the browser pops open, and within seconds the app is live. If something needs tweaking, you just type it in the terminal (promptyly> add export to CSV) and watch it update.
• Portable and Packaged: Because the local JSON database resides inside the app’s folder, you can run promptyly export <name> to bundle the entire project (code, git history, and your actual data/state) into a single .zip file. Your friends can import it and it works instantly with the database intact.
• Promptyly Hub: Serving a beautiful dark-mode dashboard at http://localhost:6071 that lists all your generated apps, their creation prompts, and metadata makes managing local projects very clean.

The Bad

• The Single-Writer DB Bottleneck: While the local JSON database works wonders for private local tools, it doesn’t scale. If you publish your app to the public Sharing Registry (port 6072), multiple users writing to a single JSON file will immediately hit conflicts.
• Browser Sandbox & Protocol Prompts: Every time the browser tries to trigger a deep link, it pops up a warning dialogue asking for permission to open Promptyly. It’s a security feature, but it slightly breaks the smooth “web-to-desktop” magic.
• Windows File Locking: Upgrading the Go binary on the fly is tricky on Windows because running executables are locked. I had to write a PowerShell loopback script that waits for the CLI process to terminate before hot-swapping the executable.

The Conclusion

Promptyly is the developer’s scratchpad I’ve always wanted. It bridges the gap between high-level prompt engineering and local system control.

Instead of configuring configurations, downloading massive npm modules, and spending half an hour setting up boilerplate code for a weekend project, I can just prompt my way to a functional tool in under a minute.

The Future

Right now, Promptyly edits single files sequentially. The next step is introducing Agentic Team Collaboration (similar to what tools like Antigravity do), allowing multiple specialized LLM subagents to edit complex layouts, write tests, and interact with directories in parallel.

I also want to introduce native multi-page routing templates and a standard authentication helper to secure shared registry apps out of the box.

If you want to play around with it, deployment is simplified: you can host the pre-built Docker container for the server/registry and install the local CLI to interact with it. Check out the Promptyly GitHub to get started!

What if you could build a fully functional social network, a blog, or even a banking app, without ever deploying a backend server? No Node.js API, no Go microservices, no Supabase, and no Firebase. Just a static frontend and a bucket of S3 storage.

That was the goal of SovereignS3nc. I wanted to see how far I could push the concept of a “sovereign network”—where the user truly owns their data, and the application is just a lens through which they view it.

The Vision: Zero Hosted Compute

The core idea is simple: your data lives in an S3 bucket (AWS, OCI, or self-hosted via something like RustFS). When you use an application, you connect it to your storage. You share data by giving other users permission to read specific parts of your bucket, and you follow others by reading from theirs.

Using a single statically hosted frontend, you should be able to:

1. Connect to your own data.
2. Share with other users.
3. Keep everything encrypted and private.

Pushing the Limits

I pushed this idea as far as I could, and while I hit some interesting walls, I also found some elegant ways around them.

What Works Beautifully: Private Stores & E2EE

The private side of things is rock-solid. By using local public keys and E2EE (End-to-End Encryption) via tweetnacl, your data remains secure even if the bucket itself is compromised. Since I don’t allow listing on the S3 bucket, and everything is encrypted with your local key before it even hits the wire, the storage provider is essentially a “dumb” pipe.

The backend storage model I settled on works surprisingly well: SQLite daily files per user. These databases are hashed, encrypted, and synced incrementally. It’s clean, it’s fast, and it blends perfectly with the offline-first architecture.

The Stumbling Block: Shared Resources

The biggest challenge in a serverless, backend-less world is shared state.

In SovereignS3nc, I used a users.json file at a fixed location to handle user discovery. But because multiple users need to write to it (to “register” themselves on the network), it becomes a massive bottleneck. Without a central authority or a backend server to handle user creation and custom access rights, multi-writer shared files are a significant hurdle.

The Demos: Alpha/Beta Ready

I built out a suite of demos that show what’s possible:

Social Demo

A decentralized social network with messaging and feeds.

Social Bank (Banky)

A transaction tracker that I actually use for my children’s bank accounts.

Social Blog

A decentralized blogging platform.

Social Board

A shared message board for distributed teams.

All of these are currently at an Alpha/Beta level and demonstrate that for many use cases, the “no-backend” approach is not just a pipe dream.

Lessons Learned & The Path Forward

In the end, SovereignS3nc is a perfect library for creating flexible, usable stores for personal privately hosted applications. For me, it’s the ideal way to host quick apps that I only access via a VPN.

I believe there’s still a gap in the web standards for a native authentication mechanism that can dynamically build access rights on the server side via S3 APIs. The “real” version of this concept is likely close to something like Supabase. To move SovereignS3nc forwards to something production ready, the next step would be integrating an identity provider and a minimal server to handle user registration and ACLs.

It was a great exercise in taking a concept to its logical extreme. I particularly love the idea of “pop-up” local networks—networks that exist only for a specific event, hosted entirely on the participants’ own S3 buckets.

How do you keep control without a server? How do you handle access control? I have some answers around encryption and security, but definitely still have a few unanswered questions still too.

Check out the SovereignS3nc GitHub page if you want to dive into the code.

Status: Published
Genre: Cyberpunk / Tech-Noir / Non-Fiction
Tags: #AIWriting #LLM #CreativeProcess #Cyberpunk #SoftwareEngineering

Abstract

As a programmer, my relationship with AI has mostly been about source code, building applications, refactoring functions or hunting down race conditions. Recently, I found myself craving a very specific story: a humorous, sprawling, world-spanning cyberpunk detective noir. I decided to see if I could build it.

What started as a weekend experiment in “creative prompting” turned into a massive project: The Unhandled Exceptions, a nine-book series. Along the way, I learned that writing a book with an LLM isn’t just about asking it to “write a story”, it’s about system architecture, context management, and a surprising amount of manual “Meatspace” formatting.

Phase 1: Architecting the Universe

With AI, writing the prose is easy; building a world is hard. I spent a significant amount of time in the ideation phase. This wasn’t just shouting into a void; it felt like playing a high-stakes Tabletop RPG with the AI.

I created character sheets that functioned like documentation. We traded plot ideas back and forth, I’d provide a prompt, the AI would suggest three directions, and I’d pick the most interesting “bug” to turn into a feature.

To keep the story consistent across nine books, I had to be disciplined with my “source code”:

• story.md: Mapped out the overall series arc.
• characters.md: Detailed bios and motivation trackers.
• chapters.md: Granular breakdowns of pacing and plot beats.
• synopsis.md: Book synopsis, story points, and chapter-by-chapter one-liner summaries.

I wanted to ensure the “Context Window” was always present and optimized. If the LLM forgot that Detective Miller hated “Smart” coffee, the immersion broke. I treated these markdown files as the “State” of my application.

Phase 2: The Factory Floor (Generation)

Once the architecture was solid, we moved to production. For the sake of speed and narrative flow, we generated two chapters at a time.

I set a hard constraint: 20 chapters per book.

Mapping the arc for all nine books before writing a single word of Chapter 1 was the only way to ensure that the “Zero Day” finale in Book 9 actually paid off the breadcrumbs dropped throughout the series.

Phase 3: The Polish (Iterative Editing)

The first draft is never the final product. The editing process was an iterative Q&A loop. I’d go through the chapters, identify “hallucinations” or repetitive phrasing, and we’d work together to refactor the prose.

Note: If I saw “chocolate-chip eyes” one more time, I was going to crash the system.

It was less about fixing typos and more about fixing narrative logic.

Phase 4: Logic Gates & Lost Characters

Once all the beats and rough edits were in place, I did a lot of work around book length, chapter lengths and character placement. Building skills to monitor the length of chapters and books. Building skill to identify characters in the books and their impact. Expanding in most cases, but a few times during big edits Gemini would occasionally lose the plot.

In one particular instance I had an entire chapter go missing during an unrelated edit, but thankfully due to diligent source control I was able to go back and retrieve it.

I had to spend a substantial amount of time re-integrating missing characters into the books in cases where they were under-represented.

I have immense respect for the authors I love and this process gave me another group of people to be very respectful to as well, proof readers, editors and layout experts (foreshadowing).

It honestly takes a village to grow from a baby manuscript to a book.

Phase 5: Bridging the Air-Gap (Publishing)

I decided early on that I wanted to see what it would take to go from a digital idea to a physical object on a shelf. I chose Amazon KDP (Kindle Direct Publishing) for its simplicity.

Amazon handles the heavy lifting: distribution, printing on demand, and providing the necessary ISBNs and ASINs. They take their commission and product fees, which, for a side project like this, felt like a fair trade for the infrastructure they provide.

The Hidden Boss: Formatting

If you think writing 180 chapters is hard, try getting page numbers to behave in a 400-page PDF. Formatting took a massive chunk of the post-writing schedule. You have to juggle two different “build targets”:

1. E-book: Requires an EPUB with specific Amazon-friendly formatting.
2. Paperback: Requires a precisely sized PDF.

Things like “Chapter starts on a new page,” “Footnote placement,” and “Page numbering” became my new “segmentation faults.” Even the covers were a challenge, an e-book cover is a simple JPEG, but a print cover is a complex PDF “wrap” that includes the spine width, which changes based on your page count.

Final Thoughts

Is it “cheating” to write with AI? its definitely different, but I don’t think so. I feel more like a Director or a Lead Architect. I provided the vision, the constraints, and the “human” soul, while the AI provided the raw processing power to flesh out the world.

I ended up with something I actually wanted to read. And in the process, I gained a massive amount of respect for the technical hurdles that traditional authors face every day.

💡 Tips for AI-Authors

• Markdown is your friend. It’s clean, version-control-friendly, and LLMs understand it perfectly.
• Plan the end first. If you don’t know the finale of your series and work towards it, the AI will just meander.
• Don’t skip the formatting. Use the Kindle Desktop Publishing builder, it’s a lifesaver for the cover wraps.

The Unhandled Exceptions first 3 books are available on Amazon. Not bad for a project that started with a “What if?” prompt.

Book 1 - System Exception	Book 2 - Memory Leak	Book 3 - FATAL ERROR

And more to come, see you in Neo-Viridia!

After the success of Stick Fighter, I found myself deeply attached to its core engine. The bone-based skeletal animation system I had engineered for the Arduboy felt like it had more to give. I started wondering: could this be the backbone of a classic 2D brawler?

The result is Sticks of Rage, an evolution of the Stick Fighter tech stack that transformed a 1v1 fighter into a chaotic, side-scrolling beat ‘em up.

View its game page and play it online here

Take a look at the source code here

Technology Reuse: The “Stick Engine”

The animation system migrated to the new project almost seamlessly. By reusing the core skeletal pose data, I was able to hit the ground running. I’ve tentatively dubbed this codebase the “Stick Engine.” While it started as a 1:1 port of the Stick Fighter logic, it has since been heavily refactored to support the more complex demands of a side-scrolling world.

The Evolution of the System

Taking a 1v1 engine and making a brawler required adding several new layers of depth:

• Stat-Based Gameplay: I introduced a simple RPG-lite stat system for Life, Damage, and Speed. This allowed for diverse character archetypes: big enemies hit harder and have more health but move sluggishly, while smaller ones are fast but frail.
• Parallax Backgrounds: To give the flat screen a sense of depth, I implemented a layered parallax background system. Even with simple geometric lines, the movement of different layers really sells the “traveling through a city” vibe.
• Plane Movement: Unlike Stick Fighter, which locked characters to a single horizontal line, Sticks of Rage allows players to move up and down in the plane, opening up the battlefield for strategic positioning.

Character Dynamics and Story

I took the nine original characters from Stick Fighter and re-purposed them for this new world. I chose three main protagonists for the player to master, while the remaining six were converted into distinct enemy archetypes. Each playable character now comes with their own intro and outro stories, fleshed out with “boss talk” dialogue that triggers before the big fights.

The AI Challenge: Swarming

One of the biggest shifts was moving from 1v1 combat to swarming. Enemies now use a group-based AI, employing different “personalities” to keep the player on their toes. As stages get harder, the swarm density and aggression increase.

However, this came at a cost. The ATMega32U4 is not a powerhouse. Getting multiple enemies, parallax layers, and player combat running simultaneously meant the CPU was constantly on the edge of a collapse. I had to enforce a strict limit: a maximum of four characters on screen at once. Keeping the background geometry simple was the only way to squeeze the extra CPU cycles out of the hardware to maintain playability.

The Hardest Part: The Memory Wall

The hardest part of this project, once again, was fitting it all in. Sticks of Rage pushed the memory and CPU constraints even further than its predecessor. Every byte saved in the background engine was a byte used for a character stat or a line of story dialogue.

Reflecting on Re-use

Building Sticks of Rage taught me that technical re-use is one of the most rewarding parts of software engineering. Watching a system I built for one purpose evolve to serve a completely different genre—all while staying within the same 8-bit constraints—was an incredible experience.

The game may be simple, but seeing three playable characters roaming a parallax city, battling swarms of enemies, all on a device with less power than a modern calculator? That’s the kind of technical satisfaction that keeps me building on the Arduboy.

When I first saw the Arduboy, I was immediately drawn to its charm and simplicity.

Over the years I’ve really enjoyed its community, making games for it and the big library of games available, the small system with its ability to code for so easily and its online community always bring me back for more.

I did however notice a hole in its library: there were no real-time 2D fighting games. This always bugged me, the platform was crying out for a competitive, fluid brawler, and I decided to take on the challenge.

View its game page and play it online here

Take a look at the source code here

The Vision vs. The Reality

My goal was ambitious: a fast-paced 2D fighter featuring fluid animations, varied moves, and tight gameplay. I wanted something that felt like a simplified Street Fighter but fit into the tiny footprint of the Arduboy’s ATMega32U4.

The development process was a constant tug-of-war between my design aspirations and the hardware’s strict limits. I started with grand ideas of complex combo systems, but ended up with a refined, high-intensity brawler that emphasized spacing and timing, a compromise that arguably made the final game much more enjoyable to play.

Sprites vs. Bone Systems: A Deep Dive

Early on, I had to make a critical decision: use traditional frame-by-frame sprites or a procedural bone system. Traditional sprites were memory-hungry. Loading multiple frames for different moves for even two characters would have exhausted the flash memory before I even wrote the game loop. I chose a bone-based skeletal animation system.

Traditional 3D vs. Stripped-Down 2D

In traditional 3D animation, you have a hierarchy of bones, a complex skinning system, and often a root node that controls everything. This requires high-precision floating-point math and substantial RAM.

My system for Stick Fighter takes the exact opposite approach:

1. No Mesh Skinning: Stick figures are just lines. I don’t need to skin a mesh, only render lines between endpoints.
2. No Root Hips: Instead of a complex root-node hierarchy, I use a simplified, linear connection chain.
3. Fixed Plane: Because the movement is restricted to a 2D plane, I avoid 3D rotations (quaternions) entirely. Every bone is represented simply by a start position and an angle.

Simplifying the Geometry

To avoid the performance hit of complex inverse kinematics (IK), I made two critical trade-offs:

• Constant Lengths: Since we are in 2D, the distance between joints never changes. This means I don’t need to calculate scaling factors. Each bone length is a pre-defined constant.
• Reduced Joint Complexity: By keeping the hierarchy shallow, I eliminate the need for recursive matrix multiplication.

The Mathematical “Cheat”

In Stick Fighter, I use a forward-looking pose definition. Each bone’s angle is stored relative to its parent bone. To draw a limb, I take the parent’s world position, add a simplified trigonometric calculation (using a pre-computed sine/cosine lookup table), and draw the line. Because I don’t perform complex matrix inversions or heavy transformations, the math remains manageable even for the Arduboy’s 16MHz processor.

The Technical Hurdle: Speed and Space

Implementing this on an 8-bit chip is deceptively difficult. I had to ditch standard float math for fixed-point arithmetic, and build a custom animation engine that could update character positions within the tight frame budget of the Arduboy’s screen refresh. The tooling was another challenge; I had to build a custom animation editor (in SDL) to preview and export these skeletal data structures, essentially building the game’s pipeline from the ground up.

Under the Hood: Hitboxes and AI

• Hit Detection: To save space, hit detection uses simple Axis-Aligned Bounding Boxes (AABB) relative to the bones. Since the characters are stick figures, I could use their limb vectors to create simple, fast-to-calculate collision zones.
• Enemy AI: The AI uses a simple Finite State Machine (FSM). It evaluates the distance to the player and decides between aggressive “rush down” states or defensive “spacing” states.

Everyone is a Bunch of Lines

To make each character stand out despite being simple stick figures, I developed a modular “head system.”

Instead of drawing a static circle for a head, I designed a set of small geometric primitives—simple line segments and points—that could be configured for each character. By varying the position of these “facial features” (like eye placement, hair spikes, or head accessories) and storing them as a tiny list of offsets, I could give each fighter a distinct silhouette.

Because these were just defined by a few coordinate pairs relative to the head’s bone, this system consumed almost zero additional memory, allowing me to inject unique personality into every character while keeping the animation overhead identical to a standard stick figure.

Developing for the Desktop: The SDL Wrapper

To speed up my iteration time, I built a custom SDL wrapper that allowed me to run the game logic directly on Windows. This acted as a virtual development environment for the Arduboy code.

The Pros: Rapid Iteration

• Faster Compilation: I could build a binary and test changes in seconds, bypassing the slow build and upload process to the physical microcontroller.
• Rapid Prototyping: It was invaluable for tweaking “juice” elements—like gravity, character movement speed, or animation frames—allowing me to get the “feel” pixel-perfect with ease.

The Cons: The Hardware Disconnect

• Input Differences: Keyboard input is fundamentally different from the gamepad and buttons of the Arduboy. I often found myself over-reacting or pulling off combos that were impossible on the real hardware.
• False Sense of Performance: The biggest trap was the lack of hardware constraints. I could easily blow past the 32KB flash memory limit or the tiny RAM budget without realizing it. On desktop, the game always ran at a perfect 60FPS, leaving me completely unaware that the Arduboy might actually be stuttering or running out of memory.

Balancing the Approach

To mitigate these risks, I adopted a strict “touch-base” policy. I would frequently flash the binary onto the actual console to check performance and memory usage. While emulators or regular hardware testing are necessary, the development speed gains from an SDL wrapper are absolutely worth the extra vigilance. If you pay attention to the hardware constraints, this hybrid workflow is an incredibly powerful tool.

Features Dropped and Lessons Learned

Not every idea survived. I had plans for complex stage hazards and a multi-tiered background, but they were cut to prioritize the core gameplay loop.

Playing Stick Fighter feels rewarding because of the “juice” added late in development:

• Dynamic Zooming: The camera scales and zooms based on character distance, adding cinematic flair.
• Character Scaling: Using procedural transformations to emphasize weight.
• Fireballs: Adding simple projectile physics gave the game the “spacing” element it desperately needed.

The Story and the “Wall”

Despite the technical focus, I wanted the game to have personality. I ended up adding a surprisingly large amount of story text to character introductions, giving each stick fighter their own motivations.

There is a unique kind of fun in developing under extreme constraints. When you hit the “memory wall,” you’re forced to stop adding features and start polishing what you have. You can’t just throw more code at the problem—you have to optimize, rethink, and simplify.

Stick Fighter was a masterclass in this philosophy. It was a challenging project, but very rewarding as well.

I’ve just released Axis Rush, a futuristic arcade racer inspired by the classics like F-Zero and Wipeout. The twist? You’re racing on a giant cylinder, and you can flip between the inside and outside of the track at will to dodge obstacles or find the perfect racing line.

Take a look at the demo page - Live Demo

Take a look at the code - GitHub Repository

The Vision: Redefining the Racing Line

In most racers, the “line” is two-dimensional. In Axis Rush, its a full 360-degree experience. By allowing players to jump between the Interior and Exterior of the cylindrical track, I wanted to create a game where spatial awareness is just as important as reflexes.

Flipping to the inside gives you a tighter turn radius but limits your visibility, while the outside offers a grand view of the neon-soaked horizon but leaves you exposed.

Features: Beyond the Speed Limit

• Inside/Outside Transition: Use the Space bar to phase through the track. It’s not just a visual trick—steering is dynamically inverted while inside to keep the controls intuitive from the player’s perspective.
• Procedural Aesthetics: Every texture in the game is baked at runtime using TexGenJS. I used natural language prompts like “neon circuit” and “carbon fiber” to generate GLSL-based textures, keeping the initial bundle size incredibly small.
• High-Inertia Physics: I implemented a “slippery” steering model with an angular velocity system. It feels less like driving a car and more like piloting a high-speed hovercraft with massive momentum.
• 9 Unique Pilots: From the disgraced military pilot Axel Rush to the digital consciousness Korvath, each character has a back-story and a signature color that bleeds into their craft’s neon trails.
• Thumping Techno Engine: The soundtrack isn’t just a static MP3. its a custom-coded Web Audio engine that generates procedural techno beats using oscillators and noise buffers, reacting to your speed.

Tech Deep Dive: Three.js and Post-Processing

1. The Cylindrical Coordinate System

Collision detection on a bending, twisting tube is tricky. Instead of standard XYZ coordinates, I used T-space (progress along the spline) and Angle-space (rotation around the tube). This makes checking if a vehicle is “on the track” or hitting a boost pad a simple 2D range check.

2. Post-Processing Pipeline

To capture that “retro-futuristic” vibe, I used the postprocessing library to layer:

• Motion Blur: To emphasize the extreme speeds.
• Chromatic Aberration: To simulate the visual distortion of a high-G cockpit.
• Pixelation: A subtle toggle that gives it that late-90s arcade feel.

3. Dynamic FOV and Camera Logic

As you hit boost pads or enter a slipstream, the camera’s Field of View (FOV) warps. It’s a classic trick, but combined with Three.js’s camera shake and a “zoom-in” countdown, it creates a visceral sense of acceleration.

Things I was very happy with

• The Transition Mechanic: Getting the camera to smoothly follow the vehicle as it flips from the inside to the outside of the tube without causing motion sickness was a major win.
• TexGen Integration: Seeing a complex, glowing track texture appear from just a few lines of GLSL and a keyword prompt still feels like magic.
• The Audio Engine: Generating a convincing “kick drum” and “hi-hat” purely with code was a fun challenge that paid off in a soundtrack that never sounds exactly the same twice.

Things I wasn’t very happy with

• AI Pathfinding: The AI currently follows a fairly rigid path. While they can dodge obstacles, they don’t yet “think” tactically about flipping inside/outside to overtake the player.
• Collision Response: High-speed collisions between vehicles can sometimes result in “jitter” if the physics steps aren’t perfectly aligned with the frame rate. I’m looking into implementing a sub-stepping physics loop to smooth this out.

What’s Next?

I’m working on a League Mode with a persistent leaderboard and potentially a Track Editor that allows players to draw their own splines in 3D space.

If you want to try your hand at the 2026 League, head over to the GitHub repo and give it a spin!

I built triangleVision, a high-performance video processing engine that transforms standard video or live webcam feeds into stylized, artistic triangle meshes in real-time. It uses intelligent point sampling to preserve detail while creating a unique “low-poly” aesthetic.

Take a look at the demo page - Live Demo

Take a look at the code - Code

The Vision: Turning Pixels into Geometry

Most video filters operate purely on pixels. triangleVision takes a different approach by treating the video frame as a dynamic coordinate space for geometry. The goal was to create a tool that doesn’t just “blur” or “pixelate” but actually re-interprets the visual data through the lens of computational geometry.

By using Delaunay triangulation, the video becomes a living, breathing mesh of interconnected triangles that shift and morph as the underlying scene changes.

Features: More Than Just Random Points

The magic of triangleVision isn’t just in the triangles themselves, but in how it decides where to place them:

• Intelligent Point Sampling: Instead of a uniform grid, the system uses edge detection (Shi-Tomasi) to place more detail in complex areas and fewer triangles in flat regions.
• Human-Centric Focus: Integrated HOG and Haar Cascades ensure that faces and human figures retain high fidelity, even in a highly abstracted mesh.
• Motion-Aware Density: The engine tracks movement, increasing the triangle count in areas with significant action to capture every nuance of motion.
• Custom .triv Codec: I designed a bespoke binary format to store triangle data efficiently, allowing for much smaller file sizes than traditional video when storing geometric abstractions.
• Aesthetic Modes: Beyond the standard mesh, it includes a Rotoscope mode for an “ink-and-paint” look and a Heatmap mode for technical visualization.

Tech Deep Dive: Python Meets the GPU

1. The Processing Pipeline

The core engine is written in Python, but it relies on ModernGL and custom GLSL shaders to handle the heavy lifting of rendering. This allows the system to maintain 30+ FPS even while performing complex geometric calculations.

2. High-Speed Triangulation

We use SciPy for the Delaunay triangulation, but to keep things fast, we leverage Numba for Just-In-Time (JIT) compilation of our color sampling and data processing loops. This turns bottlenecked Python code into machine-speed execution.

3. Multi-Threaded Capture

To ensure zero lag in the webcam feed, triangleVision uses a threaded capture system. This decouples the video input from the processing and rendering cycles, preventing any “hitchy” frames during live use.

Things I was very happy with

• Real-time Performance: Getting Delaunay triangulation to run at 30+ FPS on 1080p video was a significant hurdle, and seeing it run smoothly is incredibly satisfying.
• The .triv Player: The web-based player (JS/HTML) works surprisingly well, proving that the geometric data format is portable across different stacks.
• Stylized Export: Being able to export the final result back to MP4 or MKV makes it a practical tool for content creators, not just a tech demo.

Things I wasn’t very happy with

• CPU Bottlenecks: While the rendering is on the GPU, the actual triangulation calculation is still a CPU-heavy task. For ultra-high point counts (10,000+), the frame rate still takes a hit.
• Dependency Chain: The setup requires a specific set of high-performance libraries (OpenCV, ModernGL, SciPy). I’m looking into ways to package this more easily for non-technical users.

What’s Next?

I’m currently experimenting with a Vulkan-based implementation of the triangulation itself to move even more of the logic onto the GPU. I also want to add more interactive controls for VJs, such as MIDI support to trigger mesh density and color shifts during live performances.

If you’re into creative coding or computer vision, check out the GitHub repo and let me know what you think!

I built TexGen, a lightweight (~15kb) JavaScript library that leverages GLSL shaders to generate high-quality, procedural textures on the fly, including a natural language interface called “TexGen Words”.

Take a look at the site - Live Demo

Take a look at the code - Code

The Vision: Visuals with Code, Not Bandwidth

In the modern web, we often find ourselves shipping megabytes of static assets. TexGen was born out of a desire to flip that script. Why ship a 2MB PNG of a brick wall when you can ship a 1KB shader string that generates that same wall (and infinite variations of it) directly on the user’s GPU?

Whether you need static baked images for a UI or real-time animated backgrounds for a game, TexGen provides the primitives to build them without the bandwidth bloat.

Features: Beyond Just Noise

TexGen isn’t just a wrapper for a canvas; its a full-featured texture pipeline:

• Live GLSL Editor: A built-in IDE with real-time feedback and @slider annotations for interactive debugging.
• TexGen Words: An addon that allows you to synthesize complex textures using natural language. Phrases like “blue fire spiral warp” or “purple plasma vortex” are instantly converted into optimized GLSL.
• PBR Ready: Native support for Albedo, Normal, Roughness, Metallic, and Ambient Occlusion maps.
• Mobile First: Adaptive scaling for high-DPI screens and high-precision defaults to ensure consistency across mobile GPUs.
• Infinite Variety: By tweaking a single seed uniform, you can generate millions of unique assets from a single shader.

Tech Deep Dive: GPU-Accelerated Pipelines

1. The Power of FBM and Voronoi

At its core, TexGen provides highly optimized GLSL implementations of Fractional Brownian Motion (FBM), Voronoi noise, and standard Perlin noise. These are the building blocks of nature—from the way clouds form to the cracks in a dry lake bed.

2. Compact Payloads

One of the most powerful features is the URL-based sharing. Because the textures are just code, a complex atmospheric sky can be reduced to a tiny Base64 string. This “Texture Streaming” approach allows for massive world-building with minimal initial load times.

3. Asynchronous Baking

To keep the UI responsive, TexGen supports offloading the generation to Web Workers using OffscreenCanvas. This ensures that even high-resolution 4K bakes won’t freeze the main thread.

Things I was very happy with

• TexGen Words Synthesis: Seeing natural language keywords like lava, neon, and glitch successfully combine into a working shader feels like magic.
• The Example Library: I managed to pack over 50 built-in examples into the gallery, ranging from “Rusted Hull” to “Infinite Island”.
• The TypeScript Support: Adding full .d.ts definitions and a dedicated TypeScript gallery makes the library a joy to use in modern dev environments.

Things I wasn’t very happy with

• GLSL Debugging: While the editor is great, debugging shader logic is still a hurdle for those not familiar with GPU programming. I’m looking into more “visual node” based editing.
• Precision Quirks: Even with highp defaults, some older mobile GPUs still exhibit tiny artifacts in heightmaps that are hard to squash without sacrificing performance.

Showcase: Procedural Power in Practice

To demonstrate the versatility of TexGen, I’ve built a series of interactive demos that push the library to its limits. Each one highlights a different core feature while maintaining an incredibly small footprint.

Try it Yourself: Inline Examples

You don’t need a heavy engine to start creating. Here are a few ways to talk to TexGen.

1. The GLSL Approach

You can write raw shaders with interactive sliders. Here’s a simple animated plasma:

uniform float u_scale; // @slider 1.0, 10.0, 4.0
uniform float u_speed; // @slider 0.0, 2.0, 0.5

void main() {
    vec2 st = vUv * u_scale;
    float t = u_time * u_speed;
    float n = fbm(st + vec2(t, t * 0.4), u_scale);
    
    vec3 col1 = vec3(0.0, 0.2, 0.5);
    vec3 col2 = vec3(0.0, 1.0, 0.8);
    vec3 color = mix(col1, col2, n);
    
    gl_FragColor = vec4(color * (n + 0.2), 1.0);
}

2. TexGen Words (Natural Language)

If you’re not a shader expert, you can use TexGen Words to describe your vision. Try these phrases in the Word Textures editor:

• Lava Flow: lava smoke fire hot
• Frozen Tundra: icy stone marble rough
• Digital Glitch: neon digital glitch
• Mystic Forest: forest leaf grass mist
• Plasma Vortex: purple plasma vortex glow

Where to from here?

I’m just getting started with TexGen, and there is plenty more on the roadmap:

• AI-Assisted Generation: Further integrating LLMs to help users write custom shader logic from scratch within the editor.
• Node.js CLI: A dedicated build tool for pre-baking textures as part of a CI/CD pipeline.
• Three.js / Babylon.js Plugins: Official wrappers to make procedural texture injection as simple as a single line of code.

If you’re a game dev or a web artist looking to save some kilobytes, give TexGen a spin!