Games, tools, utilities, experiments, and other things I built because the thing I wanted either didn’t exist or wasn’t doing what I thought it should.
The projects I am actively pushing forward now.
A browser-based post-apocalyptic RPG built around persistent geography, persistent creatures, survival, and a story that starts with the remains of one family before it opens into something much larger.
Fallen World is a working prototype title. The current public build is prototype 1.20.0 and will continue changing as the game develops.
Play the prototype →
I needed believable worlds for a game and discovered I was terrible at drawing them. I tried hand-built text maps, then color-coded images analyzed pixel by pixel. Eventually I realized I was solving the wrong problem: instead of building a better way to draw a world, I could build software that generated one.
The proof of concept. The interface was crude, but the important thing happened: the browser could generate the world instead of making me draw it.
The idea became a real tool: a much better interface and substantially more sophisticated procedural world logic.
RhinoBuilder 3 · 2026 is in progress.
Explore the RhinoBuilder progression →When tipping became ridiculous, I wrote software about it. The original version dates to 2018; a second generation followed around 2020, and TipAssist v3 is the 2026 resurrection.
TipAssist timestamps the actual dining experience—drink order, arrival, appetizer, entrée, bill—and combines those timings with questions about the restaurant and service. Instead of simply suggesting a percentage, it applies an explicit scoring methodology.
“Way back in the “before-time,” a customary tip at a dining establishment was 15%... Then came 18%. Then 20%. Then 25%. Then take-out screens demanding tips. And diners have had enough.
Tip Assist is an objective dining tip assessment tool designed to help cure this diseased tipping scheme.”
Christmas of 1979. Dad came home with a used Apple ][+. (How he got it, entirely legally, is entirely another story.) It was the whole shebang: The computer, a 9-inch black-and-white monitor, two floppy drives, an Epson MX-80 printer, and a big box of tractor-feed paper.
I'd already had experience with Apple computers from school. Dad also bought me a few games: Gorgon, Bug Attack, and Hadron. I played the hell out of them (especially Hadron). Before long, friends with similar computers and I were... talking all about and sharing stories of our games. Yeah. Talking.
One day a friend showed me how to look at source code. He goes “Watch this”, and types LIST after I'd loaded Oregon Trail. 64 pages of Applesoft BASIC flooded the screen. It went by too fast to read. So I printed it. All 64 pages.
And I began to read it.
One night, some time after I had gone to bed, Dad peeked into my room and found me with a flashlight in hand and a long trail of tractor-feed paper all over the floor.
“What do you think you’re doing?” he asked.
“Reading.”
Then he looked closer at what I was actually reading.
“Just what in Sam-Hell are you reading?”
He was very fond of that odd “Sam-Hell” saying.
I showed him: I was reading the source code to Oregon Trail. And I was learning a lot.
There was no reprimand for staying up past bedtime. Dad just gave me a rather odd look, said, “Okay ... you keep reading there,” and quietly left.
As time went on, I printed out the source code to nearly every Applesoft and Integer BASIC program I could find, and tried to understand what every line did. I modified stuff. I broke stuff. I fixed stuff. In 1980 there were not a lot of programming books aimed at a curious nine-year-old, so the Applesoft BASIC manual that came with the computer—and other people's source code—became my curriculum.
I wasted a lot of tractor-feed paper. Fortunately Dad bought it by the box for his office, and the ribbon cartridge in that Epson MX-80 seemed to last for years.
Within a year or so I had written my first little adventure game. A year after that came Kill The Tank, an artillery-style game that other kids at school actually wanted copies of. I started messing with PEEKs and POKEs, built a crude form of copy protection into Applesoft BASIC, pushed Kill The Tank toward something more like a first-person arcade game, and started work on a player-editable dungeon.
Much later I dabbled in Pascal, Ada, C and assorted scripting languages, but JavaScript turned out to fit the way I liked to work: almost no setup, no proprietary SDK, and ideas could be tested immediately. For a while, most of that experimenting happened on the ferry to and from work.
That’s literally how I learned to code: by taking things apart until I understood enough to build my own.
Some of these solved real problems. Some were experiments. Some existed because the thing I wanted didn’t exist yet.
An old-school adventure/RPG engineered to run smoothly on an iPhone 3G. No frameworks. Very little performance headroom. Maps, movement, combat, towns, ships, inventory, state and interfaces all had to cooperate on hardware that now seems prehistoric.
The technical piece I’m proudest of is the custom line-of-sight blocking system: a visibility approach I designed to be both accurate and computationally lean.
A tiny browser fighting game I built with my son as a programming lesson. We assembled it from the logic outward: state, player choices, random NPC behavior, attack and defense phases, damage, graphics, sound, and interface updates.
Three versions survive. They make a surprisingly good little record of how the game grew while the programming ideas were being taught.
Every combat sound is my voice — the same homemade sound effects used in Treason.
See the teaching game →An experiment in making the smallest directly distinguishable alphanumeric font I could manage. The core characters live on a 3×3 grid and are rendered as graphics so they can be manipulated and printed at absurdly small physical sizes.
The important part is scale. So this image is shown at its actual original size:
“A submarine is a watercraft capable of independent operation underwater. It differs from a submersible, which has more limited underwater capability. The term submarine most commonly refers to a large crewed autonomous vessel. However, historically or colloquially, submarine can also refer to medium-sized or smaller vessels (midget submarines), wet subs, remotely operated vehicles or robots.”
The inspiration came from staring at small bathroom floor tiles. An occasional occurrence.
Open TinyFont →Sometime around 1997, I taught myself HTML from fourteen photocopied pages of instructions. Then I started using Adobe PageMill because it was easier.
That lasted until I looked closely at the HTML PageMill generated. It was messy and terribly inefficient. So I mostly abandoned the tool and went back to writing the underlying HTML myself.
Use the tool. Look underneath it. If what it’s doing is stupid, take control of the system yourself.
I still have an archive of almost every version of my personal site since then. I’m sorting through the archaeology now.
I built this as an experiment in combining data that normally lives in completely different conversations.
Political control of the presidency, House, and Senate. The Dow. Nasdaq. S&P 500. Oil. Gas. Gold. Exchange rates. Interest rates. Inflation. Unemployment. Minimum wage. Household income.
None of those measures share the same units, scales, or ranges, which makes direct comparison basically useless.
So I normalized each series to a common 0–100 relative scale and built an interactive interface that let the user turn individual measures on and off, change the year range, and compare them against shifts in the political climate from 1900 through 2013.
The point wasn’t to prove a political theory.
The point was to see what became visible when radically different datasets could finally be looked at together.
The underlying values remained accurate; only their display scale was normalized so datasets with wildly different units could occupy the same analytical space.
Open the original experiment →While I was between jobs, I started building a web application that would give motorcycle dealerships a much better view of the used-bike market around them: what was being advertised, which makes and models were common, how bikes were priced, how the mix was changing, and what the broader market looked like.
The difficult part wasn’t drawing charts. It was making inconsistent human-written listings behave like structured data. I wrote the parser, the classification logic, the supporting model and MSRP data, and the browser-side analytics. One archived working dataset contains more than 5,000 motorcycle listings.
I got pretty far with it. Then somebody else produced a more polished commercial version of essentially the same idea and actually got it to market. Annoying? Absolutely.
But I had already built the data-acquisition, normalization, classification and analytics machinery myself. In retrospect, that’s the part of the project I care about.
Open the original Bikes By The Numbers project →I recently recovered a pile of old Microsoft BASIC for Macintosh programs from AppleWorks/ClarisWorks documents. The source survived. The environment did not. So I reconstructed the programs in JavaScript and made them run again in a browser while keeping the original logic, oddities, and limitations wherever practical.
An attempt to improve on an old Apple ][+ shooting game by hiding the actual point of aim. Two stick guns in the lower corners angle toward an invisible mouse-controlled target, so you have to infer where the shot will land. The enemy square also fires back into a kill zone.
A first-person dungeon interface inspired by Richard Garriott's Akalabeth. The interesting part was not just the faux-3D view: the dungeon itself could be designed in data lines using map-square codes, then interpreted and drawn by the program.
A graphics-manipulation experiment inspired by a Casio watch that displayed a tiny running person. I wanted to recreate the figure and make the motion look convincing, which mostly came down to getting the animation timing right.
An experimental interface for a possible combat game. You choose a destination on a grid and the program moves the player's square toward it, stepping diagonally until one axis matches and then finishing along the other.
An automated craps simulator that followed a predetermined betting pattern, ran as many trials as requested, tracked the bankroll, and could print the results. It was basically an early Monte Carlo experiment before I knew to call it that.
An overworld-style interface influenced by Ultima III and Odyssey: The Complete Apventure. A stick-figure character moves in eight directions and can be armed with a tiny sword.
A small trajectory plotter written after I had learned to make a missile-tracking program in Ada at Cal Poly Pomona. It accepts thrust and an angle, then draws the path of the projectile.
I had learned that computer-generated random numbers were not truly random, so I tried to improve them by repeatedly reseeding the generator with values derived from the current date and time. The output drives random walks until they hit an edge of the screen.
Games, analytics, tiny fonts, world generators, restaurant scoring systems, old web pages—the common part is wanting something to behave differently, then getting curious enough to build it.
← Back to the main site