Robert Dugger — Dev Blog

Tag: genetics

  • I built the same game for 20 years without knowing it

    I want a world that doesn’t stop when I do.

    I didn’t know that’s what I wanted until recently. But it explains every project I’ve shipped for twenty years, and it started with a browser RPG I played in middle school during summer school.

    Lands of Hope is still live. You can play it today. Deep content, crafting queues, a community that made the world feel like it mattered. What hooked me wasn’t any single mechanic. It was the feeling that the world kept going without me. Things set in motion with consequences I had to wait for. Other people in it, doing things alongside me, making it real.

    I was thirteen. I didn’t have language for what I wanted. I just knew how it felt.

    —

    TurboShells came first. Turtle racing where every turtle’s body assembled from its genome at render time — shell radius, leg length, color expressed from a genetic sequence. The turtles raced. The faster ones bred. The slower ones didn’t. Nobody played TurboShells. But I built it anyway, because something about setting a breeding pair in motion and waiting for the result felt right in a way I couldn’t explain.

    rpgCore next. A thousand tests. A proper ECS architecture. Genetics, lifecycle, dispatch — everything composable, everything persistent. SlimeGarden put it to work: breed slimes, dispatch them, see what comes back. OperatorGame pushed the dispatch loop into squad tactics. VoidDrift stripped it down to its core: drones go out, mine asteroid ore, return, station inventory updates, repeat.

    Every project had the same shape underneath. Something goes out without me watching. Time passes. Something comes back changed.

    —

    The recognition came slowly. I was writing VoidDrift’s Scout dispatch system one night — drones leaving the station, doing their work autonomously, returning with ore — and I stopped. I’d written this before. Not something similar. This exact thing. The same send, wait, return, consequence that the breeding pairs were running. That the slimes were running. That my Lands of Hope crafting queues were running when I was thirteen.

    I opened a list of every project I’d shipped and read it from the top. The dispatch loop was in all of them. Not because I’d planned it. Because I kept arriving at the only mechanic that produced the feeling I was chasing.

    A world that goes on without you. That changes while you sleep. That has consequences whether you’re watching or not.

    ContentPipeline publishes while I’m at work. PrivyBot fires its morning briefing whether I’m awake or not. RALPH ran overnight tasks the first night I deployed it and had results waiting when I woke up. VoidDrift’s drones mine whether the screen is on.

    I haven’t been building games. I’ve been building persistent worlds.

    —

    The surprise was that naming it didn’t feel like a limitation. It felt like a body of work.

    Scattered projects suddenly had a spine. TurboShells wasn’t a side project that went nowhere — it was iteration three on something I’ve been refining since middle school. rpgCore wasn’t over-engineering — it was building the foundation the loop deserved. VoidDrift isn’t just a mining idle game. It’s the clearest version yet of the thing I’ve been trying to make since I was thirteen.

    The struggle was that I couldn’t have named this pattern while I was inside it. Patterns are invisible to the person living them. You need the list, the distance, the moment when you stop mid-implementation and recognize the shape.

    —

    AntColony is next. Same chassis as VoidDrift, same loop underneath — workers dispatching, foraging, returning, colony state updating without you. Different world. Same feeling.

    I know what I’m building now. I’m building worlds that don’t stop when I do.

    I’ve always been building that. I just needed twenty years to see it.

  • What Ants Taught Me About Systems Design

    What Ants Taught Me About Systems Design

    Before programming, there were ants.

    Not metaphorical ones. Real colonies — pheromone trails that appear from nothing, queen mortality absorbed without panic, chambers organized by workers who’ve never been given instructions. No central controller. No plan. Just rules simple enough to follow and complex enough to produce something alive.

    When I started building software, I was chasing the same thing.

    AntSim is an evolutionary ant colony simulation with split-view rendering. The top two-thirds is the foraging ground — pheromone trails building and fading in real time. The bottom third is the colony cross-section: chambers, tunnels, brood, storage.

    The genetics system controls five traits per ant: sensitivity, speed, boldness, lifespan, energy efficiency. That’s it. Five genes. The colony doesn’t know it’s evolving. Individual ants don’t know they’re part of a system. They follow their traits and the colony either survives or it doesn’t.

    When a queen dies — randomly, the way queens do — workers autonomously identify royal jelly candidates and raise a successor. Colony continuity without external control. The system just continues.

    The original genetics system had too many genes. Forty variables, every trait interacting with every other. The ants evolved into creatures that couldn’t survive their own complexity — biologically sophisticated and functionally useless.

    Stripping back to five traits was uncomfortable the way all simplification is uncomfortable. It felt like giving up. What I got instead was emergence — behaviors I didn’t design, produced by interactions I didn’t anticipate, between five simple numbers and enough time.

    The cross-section visualization is still in progress. Phase 3 rendering complexity exploded the moment I made it detailed. Individual chambers, tunnel geometry, precise brood locations — the simulation could handle it but the renderer couldn’t. I scaled back. It’s still on the list.

    Here’s what I didn’t understand when I started: I wasn’t building a simulation. I was building a philosophy.

    Every system I’ve built since has the same underlying shape. Something dispatches — an ant, a Scout drone, a queued job, a breeding pair. It does its work without supervision. It returns with a result. The colony, the station, the codebase, the task queue — they change accordingly.

    That loop appeared first in an ant colony. It’s in VoidDrift’s Scout dispatch. It’s in PrivyBot’s job queue. It’s in rpgCore’s genetics engine. I’ve been building the same system for years in different materials.

    Emergent behavior doesn’t require complex rules. It requires simple constraints, honest consequences, and enough time to surprise you.

    The ants figured that out long before I did.

  • From Genetics to Tactics: How a Breeding System Became a Squad Game

    From Genetics to Tactics: How a Breeding System Became a Squad Game

    SlimeGarden had a good idea: crash-land an astronaut on a strange planet, have them breed and dispatch slimes, watch the genetic loop produce something you didn’t design. The mechanics were there. The world wasn’t quite right.

    So it evolved.

    OperatorGame is what SlimeGarden became when I pushed the genetics into a tactical direction. Instead of slimes, genetically unique operators. Instead of a crashed astronaut, a squad commander deploying crews to a resonant planetary surface. The core loop shifted from “breed for optimization” to “assemble for mission success” — still dispatch-based, still consequence-driven, but with a layer of strategic intent the breeding sim never needed.

    The architecture held up. 145 unit tests. 52+ Architecture Decision Records — one for each decision that could have sent the codebase sideways. Lock the genetic engine first, build the dispatch simulation as a separate layer that consumes genetic traits as inputs. Systems that shouldn’t couple don’t.

    The Android pipeline worked. Real Rust, real cdylib, real APK on a Moto G 2025. Wall-clock async timers that survived background processes, sleep states, and WASM contexts well enough that the edge cases weren’t blockers.

    The game stopped just short of the Play Store. Not because of code. Not because of architecture. Because somewhere in the process the compelling reason to keep playing hadn’t fully materialized. The systems were sound. The experience they produced wasn’t yet what the concept deserved.

    There’s a version of that decision that feels like failure. There’s another version where you recognize you’ve built the proof of concept the next project needed.

    VoidDrift went straight to itch.io and skipped the Play Store entirely — that was the lesson OperatorGame taught. The pipeline works. The audience question is separate. You don’t need a Play Store listing to find out if anyone cares. VoidDrift is live. A small audience that keeps coming back.

    OperatorGame could join it on itch.io. The Android build exists. The pipeline is proven. Three assets from having a page — an icon, a feature graphic, two screenshots. Whether the resonant planetary surface finds an audience is a question only publishing answers.

    The idea that started as SlimeGarden is still alive. It just hasn’t shipped yet.

  • Why I Put a Genetic System in a Turtle Racing Game

    Why I Put a Genetic System in a Turtle Racing Game

    The NEAT algorithm that taught a paddle to play Pong is the same algorithm that maps genetic traits. Someone pointed that out and I couldn’t stop thinking about it.

    TurboShells started as a question: what if the turtle’s body came from its genome? Not as an abstraction — literally. The genome string B1-S2-P0-CFF0000 encodes four values: body type, shell type, pattern, color. The frontend parses that string and assembles the turtle from layered sprites with dynamic tinting. Change the genome, change the animal. Every turtle on the roster looks different because every turtle is different — genetically.

    That’s the Paper Doll system. A compact encoding that drives visual rendering, persists across races, and accumulates history. A turtle that wins races has a record. It has traits. It has a string that says exactly what it is.

    The project grew. What started as a breeding simulation became a real-time multiplayer racing game: FastAPI backend running 60Hz physics, WebSocket broadcasting race state at 30Hz, React and PixiJS on the front end interpolating between ticks. An NPC Manager generates persistent AI turtles that populate the roster when human players aren’t racing.

    The architecture is genuinely layered — simulation core, server bridge, frontend rendering each in their own boundary. The genome doesn’t know about rendering. The race engine doesn’t know about WebSockets. The Paper Doll assembler doesn’t know about physics.

    The lesson from PyPong was that the interesting thing about NEAT wasn’t the Pong — it was the emergence. Random variation, selection pressure, something that looks like intelligence appearing from simple rules.

    TurboShells is the same idea with different materials. The turtle’s genome isn’t optimized by NEAT weights. It’s expressed as a visible body, a race record, a persistent identity. You’re not watching neural networks compete — you’re watching genetic variation play out in real time across a roster of animals that have history.

    That’s the loop I keep building. Different game, different encoding, same underlying question.

← rfditservices.com