Two small CLI tools that pull your Liked Songs, your playlists, and your YouTube rips out of the cloud and onto a drive you actually control.

Stack Python 3.10+Depends on spotipy · spotdl · youtube-dl · ffmpegLicense surface your own library

Every streaming library is a loan. The playlist you spent three years curating, the “Liked Songs” pile that’s basically a diary — none of it is a file you hold. A label dispute, a market exit, a quietly revoked license, and a chunk of it is just gone. Spotster is the fix: point it at your Spotify account or a YouTube playlist, and it writes real MP3s to a real folder, organized the way a record collection is organized — by artist.

A CSV IS A RECEIPT. IT TELLS YOU EXACTLY WHAT YOU OWNED, EVEN AFTER THE FILE IS GONE.— why export comes before download

WHAT’S IN THE REPO

Spotster is two independent tools sharing one dependency list. Neither needs the other to run.

export_library.py → download.py

Authenticates against the Spotify Web API, paginates through every Liked Song and every playlist you own or follow, and writes it all to one flat CSV. A second script reads that CSV and hands the track URLs to spotdl, which resolves each one, downloads the audio, and tags it.

export_library.py · download.py · requirements.txt · .env.example

download_youtube_playlist.py

Hands one or more playlist URLs to youtube-dl with --ignore-errors, so one region-locked or deleted video doesn’t kill a 300-track playlist. Swap in yt-dlp with a single flag when upstream inevitably lags YouTube again.

download_youtube_playlist.py

THE SPOTIFY SIDE, STEP BY STEP

First, the export. This talks to Spotify only — no audio touched yet, just metadata:

spotster — export_library.py

$ python export_library.py -o spotify_library.csv
Fetching Liked Songs...
Fetching playlists...
  fetching playlist: Basement Tapes
  fetching playlist: Late Shift Only
Wrote 2,184 rows to spotify_library.csv

The CSV is the whole point. It’s diffable, greppable, and survives every future decision you make about where the audio actually lives:

SOURCE	TRACK_NAME	ARTISTS	ALBUM	DURATION_MS	ADDED_AT
Liked Songs	Sundown	Gordon Lightfoot	Sundown	212506	2019-03-11
Basement Tapes	Wish You Were Here	Pink Floyd	Wish You Were Here	334743	2021-07-02
Late Shift Only	Nightcall	Kavinsky	OutRun	256000	2022-11-19

Then the download. It reads that same CSV, dedupes the track URLs, and calls spotdl in batches of twenty so one broken match doesn’t stall the whole queue:

spotster — download.py

$ python download.py spotify_library.csv -o Music --format mp3
[1/110] downloading 20 track(s)...
[2/110] downloading 20 track(s)...
Downloaded 2,184 track(s) into Music/<artist>/

The output template does the filing for you — Music/{artist}/{title}.{output-ext} — so a library that was one long undifferentiated list in the app comes out the other side looking like a shelf.

SPOTIFY APILiked Songs + playlists

→

CSVone row per track

CSVspotify_library.csv

→

MUSIC/<ARTIST>/spotdl, batched

THE YOUTUBE SIDE

No API keys, no CSV — just a playlist URL and a folder. Point it at as many playlists as you want in one call:

spotster — download_youtube_playlist.py

$ python download_youtube_playlist.py "https://www.youtube.com/playlist?list=..." -o Music

Same idea as the Spotify side, one level less granular: since YouTube doesn’t tag an “artist” the way Spotify does, tracks land in Music/<uploader>/<title>.mp3 — the channel stands in for the artist folder.

GETTING IT RUNNING

Everything needs Python 3.10+ and ffmpeg on PATH — both downloaders shell out to it for transcoding.

setup

$ pip install -r requirements.txt
# spotipy, spotdl, youtube-dl

$ cp .env.example .env
# fill in SPOTIPY_CLIENT_ID / SPOTIPY_CLIENT_SECRET
# from a Spotify Developer Dashboard app
$ export $(grep -v '^#' .env | xargs)

The Spotify OAuth step opens a browser exactly once per machine; spotipy caches the token afterward, so re-runs of export_library.py don’t ask again.

WHY IT’S BUILT THIS WAY

• The CSV is a checkpoint, not a formality. If spotdl falls behind Spotify’s API tomorrow, you still have a complete, portable record of what you owned — grep it, diff it, hand it to a different downloader entirely.
• Batching over one giant call. Download requests fail one track at a time, not all at once — twenty per spotdl invocation keeps a single bad match from taking down a 2,000-track run.
• youtube-dl today, yt-dlp tomorrow. The upstream youtube-dl project ages faster than YouTube changes its player. download_youtube_playlist.py --downloader yt-dlp is a one-flag swap to the actively maintained fork, same options, same output layout.
• Two scripts, no framework. Nothing here needs a server, a database, or a config language. It’s argparse and subprocess — read it in five minutes, and it still works after you stop thinking about it.

GET THE REPO

PETERALCOCK/SPOTSTER

git clone https://github.com/peteralcock/spotster

(Play it at https://peteralcock.com/paleofury.html)

I was eleven years old the first time I tried to build this game.

I don’t remember exactly what set it off. Probably some combination of Mortal Kombat at a friend’s house and a dinosaur phase I never fully grew out of. But I remember the idea landing fully formed, the way big dumb ideas do when you’re a kid and haven’t yet learned to talk yourself out of things. A fighting game, but everyone’s prehistoric. Cavemen with clubs. Velociraptors that fight like ninjas. A gorilla you could actually pick. And at the top of it, looming over the whole roster, a T. rex boss you weren’t supposed to be able to beat.

I was so sure of this idea that I did the only thing an eleven year old with no plan can do. I asked my parents to buy me a C++ book.

I want to be honest about how little this accomplished. I did not learn C++. I learned that a semicolon goes at the end of a line, and I learned that “Hello, World” is apparently the first thing every programmer in history has to type before they’re allowed to do anything else, and then I hit a wall made of pointers and header files and Visual Studio project settings I didn’t have the vocabulary to even ask questions about. There was no forum I knew to search. There was no tutorial calibrated to “kid who wants to skip straight to boss fights.” The book sat on my shelf being a monument to the gap between wanting to make something and knowing how, and eventually the dinosaur fighting game quietly stopped being a project and became one of those someday ideas. The kind you mention at parties as a fun fact about yourself and never actually revisit.

That gap, between the idea and the execution, is probably the single most common reason creative projects die. Not lack of imagination. Lack of the thousand boring technical skills standing between you and the thing in your head.

The gap closes

I’m not going to pretend the last twenty five years didn’t happen, or that I forgot about this idea and rediscovered it in some poetic way. It just sat there, occasionally resurfacing when I saw a good dinosaur documentary or played a fighting game with a particularly good roster screen. What changed is that the cost of closing that gap collapsed.

I built the whole thing, start to finish, playable in a browser, no installs, no build pipeline for the person playing it, for about twenty dollars in AI tokens, working with Claude. Twenty five years ago that number would have been “an entire computer science degree, or nothing.” Now it’s less than a used copy of the C++ book I bought as a kid.

I want to walk through what actually got built, because I think the interesting part isn’t “AI made a game.” It’s what it took to make this specific game. The actual design decisions, the actual engineering, because none of that went away just because the barrier to entry did.

What “prehistoric Mortal Kombat” actually requires

The one line pitch is easy. Making it hold together as a game is not, and this is where the eleven year old version of the idea and the real version diverge.

The roster had to make weight class sense. My original mental image had a T. rex just casually fighting a caveman, because I was eleven and hadn’t thought about it for more than four seconds. But if you actually sit with the idea, a T. rex versus a human isn’t a fight, it’s a paragraph in a nature documentary. So the roster got split by scale. Cavemen, velociraptors, and a sabertooth cat all sit in roughly the same size and speed class and can meaningfully fight each other. A gorilla and a terror bird slot in as heavier and lighter variants of that same tier. The T. rex sits alone, above everyone, as the final boss. Not a starter pick, something you unlock only after you’ve beaten the ladder. Getting that hierarchy right mattered more to the game feeling right than almost anything else I built.

Every character needed a genuinely different body. A fighting game roster is boring if everyone is the same skeleton in a different skin. So instead of one humanoid rig with reskins, I ended up with five distinct anatomies built from scratch. Bipedal humans, a gorilla frame with a heavier low center of gravity, raptors with tails and horizontal spines, a low quadruped cat build, a bird with wings that actually flap during jumps, and the oversized Rex rig built on its own proportions entirely. Each one needed its own procedural animation logic. A raptor’s tail has to counterbalance during a kick the way a human’s arms do, a bird’s wings need to drive the airborne pose instead of arms, a quadruped’s four legs need a completely different walk cycle than a biped’s two. None of that is copy paste. Every rig is its own small animation system.

The world had to sell “prehistoric,” not just state it. Street Fighter and Mortal Kombat live and die on their backgrounds, crowds reacting, environments that feel alive around the fight. So the four stages aren’t static art, they’re small simulations. A jungle canopy with eyes that blink and peer out at random intervals. An ice age tundra with mammoths actually walking a patrol path in the background and cavemen huddled at a fire that flickers with real light. A Jurassic valley with an active volcano breathing smoke and pterosaurs looping overhead. A firelit cave with hand drawn cave paintings on the walls and drummers keeping time. The crowd figures even get more excited, more arm waving, more jumping, when a fight is going well, tied to the same excitement variable that drives camera shake on a big hit.

It needed the moves that make a fighting game a fighting game. Not just punch and kick. Blocking with proper chip damage, hitstun, knockback that varies by move weight, combo detection and scoring, hitstop on impact so hits actually feel like they land, screen shake, a slow motion K.O. moment. Every character also got a signature special move that had to be hand designed around what that creature would actually do. A caveman throws a boulder, a raptor pounces, a dilophosaur spits venom, the gorilla slams the ground in a shockwave, the sabertooth lunges with its jaw, the terror bird lets out a sonic screech, and the Rex, appropriately, just stomps the entire arena.

None of this is exotic. This is the standard grammar of the genre. But it’s a lot of standard grammar, and it’s exactly the kind of thing that eleven year old me had no path toward learning fast enough to stay excited about the project.

Actually building it

The engineering choice underneath all of this was WebGL via Three.js, rendered at a deliberately low internal resolution and upscaled with nearest neighbor filtering. That’s the trick that gets you genuine chunky pixel, Sega Genesis era readability instead of the smooth shaded “3D blobs” look that so much amateur 3D falls into by default. Every character got a toon shaded material and a rendered outline pass so the sprites read cleanly against the busy backgrounds, the way 16 bit fighters always separated foreground from background at a glance.

Working with Claude on this wasn’t a matter of typing “make me a dinosaur fighting game” and getting something finished. It was closer to actual game development, just compressed. I’d describe what I wanted (arrow keys weren’t registering during character select, the sprites needed way more surface detail, two player mode needed to be ripped out entirely and replaced with proper single player systems), and we’d iterate against a real, running build. Difficulty tiers. A survival mode with escalating waves and a boss fight every fourth round. Score tracking with session bests. The kind of feature list that, as a kid, would have taken me years to work up the nerve to even attempt, because each one felt like its own multi week research project into a topic I didn’t have a name for yet.

The honest version of what changed between 1999 me and now isn’t that AI writes perfect code on the first try. It’s that the distance between having an idea and being able to test whether the idea works went from “learn a systems programming language over several years” to “describe it and see it running in the same conversation.” That distance is where almost every unfinished creative project in the world dies. Closing it doesn’t remove the craft. The weight classes, the animation rigs, the special move design all still had to be decided, and decided well, by a person who cared about getting them right. It just means the decisions get to matter more than the yak shaving required to test them.

The kid with the C++ book

I don’t think I’m owed anything for having had this idea at eleven and not being able to build it. That’s just what being eleven is. But there’s something satisfying about closing the loop, about the same dumb good idea surviving a quarter century of “someday” and finally becoming a thing you can actually open in a browser tab and play.

If you had a version of this, a project that was too big for the tools you had access to when you first wanted to build it, it might be worth going back to it. The tools changed a lot more than the idea needed to.

The game itself is called Paleo Fury. Cavemen, raptors, a silverback, a sabertooth, a terror bird, and a T. rex who is absolutely going to end your run the first time you meet him. Exactly the roster an eleven year old would have drawn on the inside cover of that C++ book, if he’d had any idea what he was looking at.

“I saved Latin. What did you ever do?”

If Professor John Keating from Dead Poets Society inspired students to challenge traditional education, Rushmore asks a modern question:

What if anyone could become a teacher?

Rushmore is an AI-powered course creation platform designed to help people transform ideas into complete educational experiences.

Instead of spending weeks creating lesson plans, gathering resources, designing materials, and formatting content, users can simply describe what they want to teach.

The AI builds the foundation.

The creator becomes the teacher.

The Magic Schoolbus for Modern Learning

Traditional course creation is difficult.

A creator needs to:

• Choose a curriculum structure
• Write lessons
• Create supporting materials
• Design presentations
• Produce videos
• Organize a learning experience

Rushmore compresses that process.

Users can enter:

• A course title
• Optional subtopics
• The number of topics they want generated
• The desired course format

The platform then creates an AI-generated curriculum.

The result is a personalized learning experience generated from a simple idea.

From Idea to Complete Course

Rushmore supports multiple types of AI-generated courses.

Video and Theory Courses

For creators who want richer learning experiences, Rushmore can generate courses combining:

• Educational concepts
• Structured lessons
• Video-based content

Image and Theory Courses

For visual learners, courses can include:

• Generated educational content
• Supporting imagery
• Written explanations

The goal is flexibility.

Different subjects require different teaching styles.

AI as the Teaching Assistant

Creating content is only part of education.

Students also need support while learning.

Rushmore includes an AI chatbot that allows learners to:

• Ask questions
• Clarify concepts
• Explore topics further

Instead of waiting for an instructor response, students have an always-available learning assistant.

The platform transforms AI from a content generator into an interactive educational companion.

A Complete SaaS Platform

What makes Rushmore interesting is that it is not just an AI demo.

It is structured as a real software business.

The platform includes:

User Accounts

Users can:

• Register with email
• Sign in with Google
• Sign in with Facebook
• Recover forgotten passwords
• Manage profiles

Course Management

Creators can:

• Generate courses
• Browse created courses
• Download course materials
• Track completed learning

Certificates

Learning platforms need proof of achievement.

Rushmore includes:

• Course completion certificates
• Downloadable certificates
• Email delivery

This turns generated content into a structured educational product.

Building the Business Layer

Many AI projects stop at generation.

Rushmore goes further by implementing the systems required for a commercial SaaS product.

The platform includes:

• Subscription tiers
• Recurring billing
• Payment processing
• Receipts
• Account management

Supported payment systems include:

• Stripe
• PayPal
• Paystack
• Flutterwave
• Razorpay

This makes Rushmore capable of supporting users across different regions and payment ecosystems.

The Admin Dashboard

Running a SaaS product requires visibility.

Rushmore includes an administrative dashboard where operators can monitor:

• Total users
• Course creation activity
• Revenue
• Paid subscriptions
• Free users
• Course types

Administrators can also manage:

• Users
• Courses
• Admin accounts
• Contact messages
• Legal pages

The result is not just an application.

It is the foundation of an online education business.

The Future of Personalized Education

Education has historically been constrained by one major limitation:

A teacher can only create so much content.

AI changes that equation.

A single creator can now generate:

• Specialized courses
• Niche training programs
• Personalized learning paths
• Educational products for small audiences

The future classroom may not be one-size-fits-all.

It may be millions of personalized classrooms created by individuals.

From Student to Teacher

The most interesting idea behind Rushmore is not the AI itself.

The interesting idea is democratizing expertise.

Someone with knowledge of:

• Programming
• Cooking
• History
• Business
• Crafts
• Languages
• Professional skills

can transform that knowledge into a structured course.

The barrier between knowing something and teaching something becomes much smaller.

Building the AI Creator Economy

Rushmore represents a larger shift happening across software:

AI is moving from being a feature to becoming a collaborator.

The next generation of SaaS applications will not simply store information or automate workflows.

They will help people create.

They will help people teach.

They will help people turn expertise into businesses.

Rushmore is an experiment in that future:

A platform where anyone can step onto the Magic Schoolbus and build the classroom they always wanted.

The teacher is no longer limited by time.

The curriculum is no longer limited by resources.

The classroom is wherever the learner happens to be.

Every organization faces the same cybersecurity challenge:

More vulnerabilities.
More threats.
More security tools.
More data.

Yet many security teams still struggle with the fundamentals:

• Where are our assets?
• Which vulnerabilities actually matter?
• What indicators of compromise are active?
• How do we track incidents?
• Who owns the response?
• What happened and when?

ZEPSEC was built to explore a different approach:

A centralized security operations platform that brings threat intelligence, vulnerability management, incident response, and security knowledge together in one system.

A Security Command Center for Organizations

At its core, ZEPSEC is designed as a security management platform.

It helps organizations organize their security operations around the things that matter most:

• People
• Infrastructure
• Threats
• Vulnerabilities
• Incidents
• Knowledge

Instead of treating every security event as an isolated alert, ZEPSEC creates a connected picture of an organization’s security posture.

Managing the Security Organization

Security does not happen in a vacuum.

A mature security program requires understanding:

• Which organization owns a system
• Which users are responsible
• Which agreements exist
• Which teams need notifications

ZEPSEC includes organization and user management capabilities to help security teams maintain this operational context.

Incident Response and Investigation

When an incident occurs, speed and organization matter.

ZEPSEC provides incident tracking capabilities for documenting and managing security events.

Security teams can record:

• Incident details
• Related indicators of compromise
• Investigation information
• Response activities

The goal is to transform incident response from scattered notes and chat messages into a structured workflow.

Threat Intelligence and Indicators of Compromise

Modern security operations depend heavily on threat intelligence.

An Indicator of Compromise (IoC) can include:

• Malicious IP addresses
• Domains
• Hashes
• URLs
• Other suspicious artifacts

ZEPSEC allows security professionals to:

• Manually add IoCs during investigations
• Enrich indicators automatically
• Share IoC data through APIs

This creates a central intelligence layer that can feed other security tools.

Vulnerability Management With Context

A vulnerability database can contain thousands of issues.

The challenge is determining what actually matters.

ZEPSEC integrates vulnerability information from the National Vulnerability Database (NVD) and allows organizations to enrich vulnerabilities with custom attributes.

This enables teams to move beyond:

“A vulnerability exists.”

toward:

“This vulnerability affects this system, owned by this team, with this level of risk.”

Context is what turns vulnerability data into actionable security decisions.

Security Scanning Built In

Security visibility starts with knowing what is exposed.

ZEPSEC includes scanning capabilities:

• Port scanning from ZEPSEC infrastructure
• Remote agents for distributed environments

This allows organizations to identify services and infrastructure that may require attention.

For distributed companies, remote agents provide flexibility for scanning environments that are not directly accessible.

A Security Knowledge Base

Security teams accumulate valuable knowledge:

• Investigation procedures
• Internal standards
• Incident lessons learned
• Security guidance

ZEPSEC includes a centralized knowledge base to preserve that information.

A security program becomes stronger when knowledge survives beyond individual employees.

Automation Through Alerts and APIs

Security operations generate constant activity.

ZEPSEC includes automated notifications for:

• New indicators of compromise
• Vulnerability updates
• Knowledge base changes

It also provides REST API integration, allowing security data to move into the broader security ecosystem.

The goal is not to replace every security tool.

The goal is to connect them.

The Open Source Security Model

One interesting aspect of ZEPSEC is its approach to distribution.

The open-source version provides a foundation for security professionals who want to explore and operate the platform themselves.

A commercial version can provide additional features, support, and enhancements.

This follows a proven open-source security model:

• Community adoption
• Professional usage
• Enterprise support

Why Security Platforms Matter

Cybersecurity has traditionally been fragmented.

Organizations often deploy separate tools for:

• Vulnerability scanning
• Threat intelligence
• Incident response
• Asset tracking
• Documentation

The result can be a collection of disconnected dashboards.

ZEPSEC explores a unified approach:

One place where security teams can understand their environment.

One place where incidents become knowledge.

One place where intelligence becomes action.

Building the Future of Security Operations

The future of cybersecurity is not just about detecting more threats.

It is about building systems that help humans make better decisions.

Security professionals need platforms that reduce noise, preserve knowledge, and connect information across the organization.

ZEPSEC represents that vision:

A security operations platform designed around the workflows that defenders actually need.

Because the best security tool is not the one with the most alerts.

It is the one that helps teams respond intelligently.

Clone it at https://github.com/peteralcock/ZEPSEC

Security teams don’t need more alerts. They need better systems.

Before every website depended on Google AdSense, before programmatic advertising became dominated by massive exchanges, publishers controlled their own advertising infrastructure.

They sold banner placements directly.

They managed campaigns.

They negotiated with advertisers.

They owned the relationship.

Aditube is an open-source experiment built around that idea:

What if anyone could clone a repository, install a web server, and run their own digital advertising platform?

Maybe they won’t make billions.

But now they have the tools.

The Personal Ad Network

Aditube is a self-hosted ad server designed for website owners, publishers, and media companies that want complete control over their advertising operations.

Instead of sending visitors through a third-party advertising network, publishers can run their own infrastructure:

• Upload advertisements
• Create campaigns
• Sell inventory
• Track impressions and clicks
• Manage advertisers
• Rotate banners automatically

The result is a miniature version of the advertising systems that power major publishing companies.

Built for the Independent Publisher

Aditube supports multiple use cases.

Website Owners

A single website owner can:

• Add banner placements
• Sell advertising directly
• Manage campaigns
• Replace external ad networks

For niche websites with dedicated audiences, direct advertising can often provide better relationships and more control than generic ad networks.

Publishers

Publishers operating multiple websites can manage:

• Multiple domains
• Multiple ad positions
• Multiple advertisers
• Campaign performance

Media Companies

Larger organizations can use Aditube as an internal advertising platform:

• Webmasters configure available placements
• Advertisers purchase campaigns
• Administrators manage billing and inventory

Supporting Modern Advertising Formats

Although banner ads are one of the oldest forms of online advertising, Aditube was designed for modern web formats.

Supported creative types include:

• GIF banners
• JPG images
• PNG images
• HTML5 advertisements
• External advertising scripts

HTML5 ads can be uploaded as ZIP packages containing:

• HTML
• CSS
• JavaScript
• Animations
• Video content

This allows advertisers to create richer experiences than traditional static banners.

Automatic Banner Rotation

A core feature of any ad server is deciding what appears and when.

Aditube manages banner positions and automatically rotates campaigns.

Publishers can define:

• Advertising locations
• Available inventory
• Multiple campaigns per position

The system handles delivery.

A website owner can create an advertising slot once and allow the platform to manage the rotation of campaigns over time.

Building a Marketplace for Advertising

Aditube goes beyond simple banner management.

It includes the foundation for a self-service advertising marketplace.

Advertisers can:

1. Create an account
2. Upload a banner
3. Select advertising placement
4. Set a budget
5. Purchase inventory

After payment, campaigns can automatically become active.

Supported payment integrations include:

• PayPal
• Coinbase

The result is a complete advertising workflow:

Advertiser → Payment → Campaign → Banner Delivery → Analytics

The Shortcode System

One of the clever engineering decisions in Aditube is the use of banner shortcodes.

Instead of hardcoding tracking URLs or metadata into every advertisement, banners can contain dynamic placeholders:

[CLICKTAG]
[ID]
[TIMESTAMP]

During delivery, Aditube replaces these values automatically.

This enables:

• Click tracking
• Dynamic campaign information
• Cache-friendly delivery
• Flexible creative management

Why Build an Ad Server?

At first glance, building an ad server might seem unnecessary.

After all, companies like Google and Meta have already solved advertising.

But that misses the point.

The modern internet has become increasingly centralized.

A small publisher often has little control over:

• Who advertises on their site
• How much revenue they receive
• What data is collected
• How relationships with advertisers are managed

Self-hosted tools like Aditube represent another vision:

A web where publishers own their infrastructure.

A Time Capsule of the Open Web

Aditube belongs to a long tradition of independent internet software.

The same philosophy powers:

• Self-hosted blogs
• Independent forums
• Open-source content management systems
• Personal analytics tools
• Independent publishing platforms

The idea is simple:

If you can run your own website, you should be able to run your own business around it.

The Future of Independent Advertising

The advertising industry has evolved dramatically.

Today, many creators rely on platforms they do not control.

But there is renewed interest in:

• Direct sponsorships
• Creator-owned audiences
• Privacy-focused advertising
• Independent publishing infrastructure

Projects like Aditube explore what that future could look like.

Not every website needs its own advertising empire.

But every publisher should have the option.

Maybe you won’t make billions.

But now you can run the server.

What if you could run your own advertising network?

Clone it at https://github.com/peteralcock/aditube

Play it at https://burnertrail.com

Brooklyn → Black Rock. 2,900 miles. Zero showers.

What happens when you take one of the most recognizable educational games of all time, replace covered wagons with a 1995 RV named Big Bertha, and send five friends across America toward Burning Man?

You get The Burner Trail — a full-stack Oregon Trail parody built for the modern desert pilgrim.

The original Oregon Trail asked players to survive a brutal journey westward through hunger, disease, bad decisions, and unpredictable weather. The Burner Trail keeps the same spirit of adventure and chaos, but swaps the frontier for a very different American migration: the annual pilgrimage from Brooklyn to Black Rock City.

The mission is simple:

Get five people, one aging RV, and enough supplies across 2,900 miles of highway before the playa market begins.

The reality is much harder.

Meet Big Bertha: Your 30-Year-Old Mechanical Liability

Every great road trip starts with a questionable vehicle.

In The Burner Trail, players take control of Big Bertha, a 1995 RV whose condition determines whether the journey becomes a triumphant arrival or a roadside disaster.

The RV has a condition meter that changes throughout the trip:

• Push too hard and breakdown risks increase.
• Ignore maintenance and repairs become inevitable.
• Run the vehicle into the ground and you may face a $300 repair bill and a two-day delay.

The game turns the classic Oregon Trail resource-management formula into something instantly familiar to anyone who has ever attempted a cross-country adventure with unreliable transportation.

A Modern Oregon Trail Built for 2026

While The Burner Trail is a parody, it is also a serious technical project.

The game was built as a complete full-stack application:

• Frontend: React 18 + Vite
• Backend: Express
• Database: SQLite with persistent Docker volumes
• Infrastructure: Terraform deployments for DigitalOcean and AWS
• Deployment: One-command cloud provisioning

A player can launch the game locally with Docker or deploy the entire application to the cloud with a single command.

The goal was not just to make a browser game, but to build a production-ready platform capable of supporting real players.

The Hall of Dust: Everyone Leaves a Mark

Death is inevitable on the trail.

But in The Burner Trail, your failure becomes part of the story.

When a player meets their fate, they can leave behind a tombstone — a digital epitaph that future travelers may discover along the route.

The game creates a shared history between players:

• Your friends can discover where you failed.
• Future travelers encounter your grave.
• Every run contributes to the growing mythology of the trail.

The leaderboard, appropriately called the HALL OF DUST, ranks every journey and immediately tells players where they stand after completing a run.

Every Choice Has Consequences

Like the original Oregon Trail, success depends on managing limited resources.

Players must balance:

• Water consumption
• Cargo weight
• RV condition
• Weather patterns
• Morale
• Travel speed
• Market timing

Even departure date matters.

Leave earlier and you have more schedule flexibility. Leave later and you risk more extreme conditions. The game forces players to make the same kind of uncomfortable tradeoffs that define real adventures.

The Fork in the Road

No road trip is complete without questionable navigation decisions.

At Chicago, players choose their route:

• The classic I-80 path
• A southern route through Denver and Moab
• A northern shortcut with greater risk

Each route changes the landmarks, weather challenges, and encounters along the way.

The game transforms interstate geography into a strategic decision rather than a background map.

From Jersey to the Playa

The journey is not just about surviving the highway.

Along the way, players encounter:

• Regional weather systems
• Scavenge opportunities
• Gift-economy caravans
• Sound-camp defections
• Supply shortages
• Random events

The final destination introduces a six-day playa market where survival continues after arrival.

Even reaching Burning Man does not mean the challenge is over.

A Retro Experience With Modern Features

Visually, The Burner Trail embraces nostalgia.

The interface features:

• CRT phosphor-inspired styling
• Typewriter text effects
• Canvas-based dust storms
• Animated environmental effects
• A shifting green-to-amber color palette as conditions deteriorate

But underneath the retro aesthetic is modern engineering.

Players can:

• Save progress through email-linked magic links
• Resume games across devices
• Share scores socially
• View rankings
• Leave persistent messages for future travelers

A Small Game With a Real Product Mindset

One of the most interesting aspects of The Burner Trail is that it was designed not only as a game, but as a potential sustainable project.

Optional monetization features include:

• Curated affiliate links for real camping gear
• Contextual recommendations based on gameplay situations
• A real-world packing list connected to in-game supplies
• Analytics designed around anonymous usage patterns

The philosophy is simple: if a player runs out of water in the game, perhaps they are interested in learning about real-world water storage. If their RV breaks down, perhaps they need camping or repair equipment.

The commercial layer stays optional and secondary to the experience.

The Spirit of the Trail

At its core, The Burner Trail is about something bigger than parody.

It captures the absurdity of modern adventure:

• Spending thousands of dollars to live without basic comforts for a week
• Driving unreliable vehicles into remote deserts
• Building elaborate temporary communities
• Trading convenience for experience

The original Oregon Trail reflected the challenges of American expansion.

The Burner Trail reflects a different kind of migration — one where people leave cities behind, chase temporary communities, and willingly trade comfort for chaos.

The destination may be Black Rock.

But the real game has always been the journey.

Welcome to the trail. Pack water. Check Big Bertha. And try not to become another name in the Hall of Dust.