• Twenty Five Years Late: How I Finally Shipped My Prehistoric Fighting Game

    Twenty Five Years Late: How I Finally Shipped My Prehistoric Fighting Game

    (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.

  • Rushmore: Building an AI-Powered Schoolbus for the Creator Economy

    Rushmore: Building an AI-Powered Schoolbus for the Creator Economy

    “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.

  • ZEPSEC: Building an Open Security Operations Platform for Modern Defense Teams

    ZEPSEC: Building an Open Security Operations Platform for Modern Defense Teams

    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.

  • Aditube: Bringing Back the Independent Web With Your Own Ad Server

    Aditube: Bringing Back the Independent Web With Your Own Ad Server

    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

  • Gekko: Building an AI Hedge Fund Where Legendary Investors Become Autonomous Agents

    Gekko: Building an AI Hedge Fund Where Legendary Investors Become Autonomous Agents

    What happens when Warren Buffett, Michael Burry, Cathie Wood, and Charlie Munger all get a seat at the same investment committee?

    That was the question behind Gekko — an experimental AI hedge fund platform designed to explore what happens when multiple artificial intelligence agents, each modeled after a different investing philosophy, collaborate on portfolio decisions.

    Gekko is not a real trading system. It does not manage money, execute trades, or make investment recommendations.

    Instead, it is a sandbox for exploring a fascinating question:

    Can the reasoning patterns of legendary investors be translated into autonomous AI systems?

    From Investment Legends to AI Agents

    Traditional investment firms are built around teams of specialists.

    A value investor might focus on discounted cash flows and margin of safety. A macro investor might analyze interest rates and economic cycles. A growth investor might search for disruptive technologies before the market recognizes their potential.

    Gekko takes that human investment committee model and transforms it into a multi-agent AI system.

    The platform includes AI personas inspired by some of history’s most recognizable investors:

    AgentInvestment Philosophy
    Ben GrahamValue investing and margin of safety
    Warren BuffettQuality businesses at reasonable prices
    Charlie MungerDurable competitive advantages
    Peter LynchPractical growth investing
    Michael BurryContrarian opportunities
    Bill AckmanActivist investing and high conviction ideas
    Cathie WoodDisruptive technology and innovation
    Stan DruckenmillerGlobal macro strategy
    Phil FisherDeep company research

    Rather than asking one AI model for an answer, Gekko creates a simulated investment committee where different perspectives can compete.

    The AI Investment Committee

    A major challenge with AI systems is that they often produce confident answers without showing their reasoning.

    Gekko approaches this differently.

    Each agent has a specialized role:

    • Fundamentals Agent analyzes financial metrics and company performance.
    • Technical Agent examines market patterns and indicators.
    • Sentiment Agent evaluates market psychology.
    • Valuation Agent estimates intrinsic value.
    • Portfolio Manager coordinates decisions.
    • Risk Manager evaluates exposure and downside.

    The result is not a single prediction.

    It is a simulated debate.

    One agent may argue that a company is undervalued. Another may warn that growth expectations are unrealistic. A third may identify technical weakness despite strong fundamentals.

    The final portfolio decision emerges from the interaction between competing viewpoints.

    Explainable AI for Investment Decisions

    One of the most interesting features of Gekko is its emphasis on explainability.

    The platform supports a reasoning mode that exposes the logic behind simulated decisions:

    --show-reasoning
    

    Instead of simply displaying:

    BUY AAPL

    the system can show the chain of thought behind the recommendation:

    • Why did the valuation agent think the company was attractive?
    • What risks did the risk manager identify?
    • Which investor persona influenced the final decision?
    • How did sentiment affect confidence?

    The goal is not just to create AI decisions.

    The goal is to understand them.

    A Full AI Trading Laboratory

    Under the hood, Gekko combines several technologies:

    AI Models

    The platform supports multiple LLM providers:

    • OpenAI models
    • Groq
    • Ollama

    This allows experimentation with different models and performance characteristics.

    React Dashboard

    The frontend provides a visual command center for observing:

    • Agent decisions
    • Portfolio changes
    • Trade history
    • Market simulations
    • Backtesting results

    The dashboard turns an abstract AI workflow into something closer to watching a real investment team operate.

    Backtesting and Simulation

    Real investors do not judge strategies based on a single decision.

    They evaluate performance over time.

    Gekko includes:

    • Historical date ranges
    • Simulated trading
    • Portfolio tracking
    • Trade logs
    • Performance visualization

    The platform allows researchers and developers to ask questions like:

    • Would a value-focused AI committee have avoided certain market crashes?
    • Would growth-oriented agents have identified emerging trends earlier?
    • How do different AI models behave under the same market conditions?

    Why This Matters

    The future of AI is likely not a single super-intelligent assistant making every decision.

    It may look more like organizations of specialized agents:

    • Researchers
    • Analysts
    • Critics
    • Strategists
    • Decision makers

    Gekko explores that idea in a familiar domain: investing.

    The project transforms investing from a single-model prediction problem into a collaboration problem.

    Instead of asking:

    “What does the AI think?”

    Gekko asks:

    “What happens when different AI perspectives argue, collaborate, and make decisions together?”

    The Future of AI Decision Systems

    Investment management is just one example.

    The same architecture could apply to:

    • Business strategy
    • Product planning
    • Scientific research
    • Security analysis
    • Legal review
    • Healthcare decision support

    Many important decisions benefit from multiple perspectives rather than one answer.

    Gekko is an experiment in building those systems.

    A virtual hedge fund.

    A simulated investment committee.

    A laboratory for exploring how AI agents can reason together.

    The market may be unpredictable.

    But the future of decision-making is increasingly looking collaborative.

  • The Burner Trail: Rebuilding the Oregon Trail for the Age of Dust, RVs, and Burning Man

    The Burner Trail: Rebuilding the Oregon Trail for the Age of Dust, RVs, and Burning Man

    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.