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!

I built a high-speed, polygonal rail shooter where you pilot a sleek craft through a relentless descent into a stylized sun, all contained within a single HTML file.

Take a look at the site - Live Demo

Take a look at the code - Code

The Vibe: Cybernetic Solar Descent

Continuing the “Vibe Coding” journey that started with Peakylight, Aussie Meme Boss Rush, and the recent TexGen, Sun Runner is my latest exploration into what’s possible with modern WebGL and a “single-file portable” philosophy.

The goal was to capture the essence of classic rail shooters like Star Fox or Rez, but with a modern, high-contrast aesthetic—think deep magentas, vibrant cyans, and a persistent wireframe grid that makes you feel like you’re diving into the heart of a digital star.

Gameplay: The Elemental Arsenal

In Sun Runner, survival isn’t just about dodging; its about mastering the elements. As you descend, you collect Earth, Water, Wind, and Fire cores that unlock devastating weapon configurations:

• Firestorm: Rapid-fire solar flares.
• Mud Slide: Slows enemies with heavy gravitational anchors.
• Dust Devil: A swirling vortex of kinetic energy.
• Chrono-Blink: A warp-dodge with I-frames that allows you to phase through incoming fire.

And when things get truly desperate, the Core Bomb provides a screen-clearing blast and a few seconds of precious invulnerability.

Tech Deep Dive: Performance in a Single File

One of the strict constraints I set for this project was Single-File Portability. The entire engine, assets (procedural), and logic are packed into index.html.

1. Procedural Environment Generation

To keep the file size low and the gameplay infinite, the terrain and obstacles are generated procedurally using Three.js. I utilized MeshPhongMaterial with flatShading: true to achieve that iconic low-poly look without the need for heavy textures.

2. Object Pooling

Bullet-hell games are notorious for creating thousands of objects, which can lead to garbage collection stutters. Sun Runner uses a robust object pooling system for projectiles, enemies, and particle effects, ensuring a consistent 60 FPS even on mobile devices.

3. Stateless Utility Systems

The collision detection and weapon mapping are handled by static utility classes. This not only makes the code cleaner but also allows for rigorous testing using Vitest, ensuring that the “math” behind the magic stays solid.

Things I was very happy with

• The Aesthetic: The combination of Fog Exp2 and the high-contrast palette creates an incredible sense of speed and scale.
• Controls: Implementing a “follow cursor” mechanic that feels responsive on both mouse and touch was a major win. The Chrono-Blink feels especially satisfying to pull off.
• The Soundtrack: Similar to my previous projects, the procedural audio provides a reactive synth-wave backdrop that scales with the action.

Things I wasn’t very happy with

• Difficulty Spike: The boss encounters can get a bit “bullet-hell” very quickly. I might need to implement a dynamic difficulty scaler based on player performance.
• Mobile UI: While the gameplay works great on mobile, some of the HUD elements can feel a bit crowded on smaller screens.

Where to from here?

Sun Runner is a technical demonstration of what can be achieved when you strip away the bloat of modern web frameworks and focus on the core experience. Moving forward, I’m looking at:

• The “Shadow Realm” Update: A secondary dimension you can phase into for extra points.
• Global Leaderboards: Because what’s a high-score game without competition?
• Persistent Upgrades: Spending “Solar Credits” to customize your ship’s starting loadout.

If you’re interested in the math behind the procedural generation or the specifics of the Three.js optimization, check out the GitHub repo.

See you in the Sun!

I made a high-octane, neon-drenched 3D boss rush shooter where you face off against cybernetic versions of Australia’s most infamous wildlife memes!

Take a look at the site - Live Demo

Take a look at the code - Code

Let’s talk about the “Vibe”.

After the success of Peakylight, I wanted to see if I could push the “Vibe Coding” methodology even further—this time into the realm of 3D gaming. I had a vision of a dystopian future where the “Bogans.exe” virus was threatening the global network, and only one thing stood in its way: a browser-based shooter featuring a Cyber Emu.

The Big Five

The core of the game is a series of boss battles against “The Big Five.” Each one is a cybernetic interpretation of an Australian icon:

1. Drop Bear: The classic ambush predator, now with more neon.
2. Cyber Emu: Fast, flightless, and surprisingly resilient to laser fire.
3. Magpie Drone: It doesn’t just swoop; it scans.
4. Cyber Huntsman: Too many legs, all of them glowing.
5. K-9000 Roo: The ultimate outback guardian.

Each boss features Soft Body Physics, meaning when you finally take them down, they don’t just disappear—they flail in glorious slow-motion ragdoll physics before exploding into a shower of confetti.

Tech Deep Dive: Making it “Sing”

One of my goals for this project was to keep it entirely self-contained. The entire game—logic, 3D models (procedurally generated), and audio—lives in a single HTML file.

1. Three.js & Procedural Shaders

Instead of loading heavy textures, I used procedural shaders to create the “neon-noir” aesthetic. This keeps the initial load time near-instant and ensures it runs smoothly on both my desktop and my phone.

2. Procedural Audio (Web Audio API)

I didn’t want to deal with MP3 files, so I used the Web Audio API to generate real-time synth basslines. The music actually reacts to the game state, intensifying as you get closer to deleting a boss. It’s amazing what you can do with a few oscillators and a dream.

3. Star Wars-Style Scrollers

To give it that “Deluxe” feel, I added cinematic story scrollers for the mission briefings. It adds that extra layer of polish that makes a “side project” feel like a “product.”

Things I was very happy with

• Mobile Accessibility: Getting the controls to feel right on both a mouse and a touch screen was a challenge, but using a dual-finger/on-screen button setup for the shield worked out better than I expected.
• The Physics: Watching a Cyber Emu tumble through a neon forest in ragdoll mode is surprisingly satisfying.
• The Workflow: Using Gemini CLI to iterate on the physics and shader logic allowed me to focus on the “fun” parts of the game design while the AI handled the heavy lifting of the WebGL math.

Things I wasn’t very happy with

• UI Scaling: In very specific portrait orientations on older phones, the score multiplier can sometimes overlap with the health bar. its a minor “bogan” in the system, but something I’ll need to patch.
• Performance on Low-End Devices: While Three.js is efficient, the soft-body calculations can get heavy on older mobile hardware. I might need to add a “Low Detail” mode similar to what I did for Peakylight.

Where to from here?

The “Aussie Meme Boss Rush” is currently in its “3D Story Deluxe” phase, but the outback is a big place. I’ve already had thoughts about:

• The Bin Chicken Expansion: A secret level featuring a cybernetic Ibis.
• Power-up System: Collecting “Meat Pies” to boost your fire rate.
• Global Leaderboards: To see who the true Cyber-Operator is.

This project further cements my belief that “Vibe Coding” isn’t just for prototypes. It’s a way to quickly bridge the gap between “I have a weird idea about a robot kangaroo” and “Here is a playable 3D game.”

Stay tuned for more updates, and remember: Watch the skies for Magpie Drones.