The Codebase That's Older Than Some of My Users' Careers
Comet has been live on Google Play since 2015. A literal look at what's still running from the original code, what got quietly rewritten, and which early decisions actually held up.
Comet has been live on Google Play since 2015. It's a small match-3-adjacent arcade game I built to learn Corona SDK, back when Corona was a reasonable way for one person to ship a cross-platform game without a real engine team behind them. It has never had a real marketing push, never made real money, and never grown. It also has never died. Eleven years later, it's still installable, still runs, and every so often still gets a review from someone who has no idea how old the thing they're playing actually is.
I went back into that codebase recently for the first time in years, mostly out of curiosity about what I'd find. Here's the honest inventory.
What's Still Actually Original
The core game loop — match detection, scoring, the board state logic — is essentially untouched since 2015. Not because it's brilliant code. It's because it's small, self-contained, and correct. It does one thing, the thing hasn't needed to change, and nothing downstream depends on it in a way that would force a rewrite. That's the actual lesson buried in this, and it's a boring one: code survives not because it's good, it survives because its job never got more complicated.
The core rendering approach is also original — Corona's display object model, largely untouched. It's dated in the sense that nobody would choose this stack today, but "dated" and "broken" aren't the same thing, and it still does exactly what it was asked to do in 2015.
What Got Quietly Rewritten
The monetization layer has been rebuilt at least three times, each time chasing whatever ad SDK hadn't yet been deprecated or acquired into irrelevance. This is the part of the codebase with the most churn by a wide margin, and it's not close — ad networks come and go on a timeline measured in a couple of years, while the actual game logic hasn't needed to change in over a decade.
Save data handling got rewritten once, early on, after I learned the hard way that the first version had a corruption bug under a specific low-storage condition that took embarrassingly long to track down. The current version has been stable since.
Anything touching platform APIs — permissions, store integration, OS-level requirements — has been touched repeatedly, not because the original approach was wrong, but because the platforms underneath it keep moving. This is the pattern across the whole codebase: the code I wrote gets to be old. The code that talks to something outside my control doesn't get that luxury.
What This Actually Says About the Original Decisions
The parts that survived intact share one trait: they were scoped tightly to a problem that doesn't change. Match logic is match logic. It was true in 2015 and it's true now. The parts that needed constant rework were the parts touching something outside my control — ad networks, platform requirements, store policy. That's not a failure of the original architecture. It's just where the actual instability in a long-lived codebase tends to live, and it's almost never in the part you'd assume from the outside.
If I'd known this going in, I might have isolated the volatile layers more aggressively from day one — cleaner boundaries around monetization and platform integration specifically, since those were always going to be the parts that needed to keep changing. The core game logic didn't need that kind of defensive architecture. It turned out to be the one part of the app that had earned the right to be written once.
Why I Haven't Killed It
Comet costs me almost nothing to keep alive — no active development, no support burden worth mentioning, just the occasional platform-compliance nudge. It doesn't move any needle for the studio. But it's also a genuinely useful artifact: it's the oldest running proof that a piece of code, scoped correctly, can outlive the tools and platforms built around it by a decade and keep functioning with almost no maintenance. That's a rarer thing in software than people assume, and it's worth more to me as a data point than it would save me by finally shutting it down.
The Bottom Line
The lesson from digging back into an eleven-year-old codebase wasn't about Corona SDK, or match-3 games, or anything Comet-specific. It's that the parts of a system worth writing carefully are the parts with a stable job, and the parts worth architecting defensively from day one are the parts touching something you don't control. I didn't fully understand that distinction in 2015. Comet taught it to me anyway, just slowly, over eleven years of mostly leaving it alone.