I loved a game that stopped updating. So I built my own.
Two years, one engine funeral, and a little robot that finally fills the screen with gold.
There's a mobile game called Alien Invasion that I have probably put more hours into than I'd comfortably admit in person. If you haven't played it: you're a tiny alien on a big hostile world, and you survive by sneaking out of your nest, eating whatever you can catch, and dragging what's left back home before something bigger eats you. Then you spend what you banked on getting slightly less tiny, and you push slightly further out. That's it. That's the whole game.
It sounds like nothing. It's everything. The loop has this quiet tension baked into it — the further you roam, the more you're carrying, and the more you're carrying, the more you have to lose. Every trip back to the nest is a small exhale. I'd play it in bed, on the train, waiting for coffee. It was my "one more run" game for a long time.
And then the updates just... slowed down. Then mostly stopped. The events started cycling the same content. The community forums filled up with people asking "is anything coming?" and getting silence back. I kept opening the app out of habit and closing it out of boredom, and at some point in the spring of 2024 a thought showed up that I couldn't shake:
If nobody's going to make more of the thing I love, maybe I should try.
That thought is now more than two years old. This post is the story of what it cost and what it turned into.
Not a sequel — I don't own anything and wouldn't pretend to. A cousin. Same family of feeling, different body. That thought turned into Mech Escape: you're a small robot waking up in a research facility that would very much like to keep you, and you fight, scavenge, and bank your way out through twelve districts, growing from a nervous little chassis into something that fills the screen with gold.
The rest is where it gets good.
The engine funeral, the wall-clip bug that quietly deleted my world, and the night a gold fan over a magenta district made two years worth it. Drop your email and read on. I send new build logs when they ship, and nothing else. No spam, unsubscribe anytime.
no thanks, just let me read →The Unity years
I started where everyone starts: Unity. That was June of 2024. It's the default answer for a reason — every tutorial on earth, an asset store, a famous engine. I dove in expecting a learning curve and found something more like a learning cliff face, and I spent the better part of two years climbing it in the hours around a day job.
The first six months barely count as game development. They were tutorial purgatory: follow along, feel competent, open an empty project, feel like a fraud, repeat. My first "playable" build — winter 2024 — was a grey box where a capsule slid around shooting spheres at other capsules, and I was so proud of it. I showed my brother. He played it for forty seconds. That forty seconds taught me more than the six months did.
Here's the thing nobody tells you about Unity as a solo beginner: the engine is fine, but you spend an enormous amount of time managing it. Meta files that break if you look at them wrong. Scenes that bake one way and load another. Prefab variants of prefab variants. Through 2025 I wrote editor scripts to build my levels because hand-placing things didn't scale, and then I wrote more scripts to fix what the first scripts did. Some nights I'd close the laptop and realize I had spent three hours on the tooling around the game and zero minutes on the game. Multiply that by a year and you understand my 2025.
Most of that year also went into an animation detour I'd rather not talk about but will anyway. Skinned characters, rigs, animation controllers, blend trees — months of it, on and off. I was terrible at it, and worse, the results looked terrible in a way I couldn't articulate yet. What finally worked, after I gave up on realism entirely, was flat billboard sprites with hand-tuned squash, stretch, hop, and lean. A little robot that bounces when it runs and tips back when it fires reads as more alive than my broken skeleton rigs ever did. It took me a year to learn what a good art teacher would have told me in an afternoon: readable beats realistic, every single time.
To be fair to Unity and to past me: I got a lot done in there. Twelve stages, an open-world conversion, a working economy, quests, even automated tests that played the game by themselves. But the screenshot above is what the game looked like after a year and a half of nights and weekends, and the honest description is "a candy sticker on a grey box." Nothing agreed with anything else. And every fix required a rebake, a re-import, a prayer.
The pivot
Early this year — a year and a half in — I admitted the thing I'd been avoiding: this is an iPhone game. It's only ever going to be an iPhone game. So why am I carrying a cross-platform engine, an editor, a licensing agreement, and a two-gigabyte project folder to draw sprites on a phone?
This spring, I rebuilt it in Swift and SpriteKit. Native, no engine, just code and a texture atlas.
I want to be honest about how scary that decision was, because "just rewrite it" is the kind of advice that ruins projects. I had nearly two years of sunk cost in Unity and no proof I could do better outside it. I sat on the decision for weeks before touching anything. What made it survivable was one decision: before touching the new project, I extracted every gameplay-feel constant from the old one into a spec file. Move speed: 7 world units a second. Fire interval: 0.40 seconds. Camera follow lerp, magnet radius, joystick dead zone — all of it, as numbers. It turns out "game feel" isn't magic; it's about forty floats. Port the floats and the soul comes with them.
The difference in iteration speed changed my mood about the entire project. Change a line, build, it's on the simulator in seconds. No editor, no bake step, no negotiation. I started actually finishing ideas instead of abandoning them halfway through the friction. The parts of the game that took me eighteen months to build the first time came back together in a couple of months the second time — partly because the second time you build anything you're faster, but mostly because the friction had been real all along and I'd been calling it "the learning curve" to avoid blaming my tools.
Collision taught me humility
When you use an engine you get collision for free and you never think about it. When you go native you write it yourself, and then it teaches you things.
My favorite bug of the whole project: players reported (okay — I discovered, at 11pm, playing my own game) that if you hugged a wall and slid along it just right, the game would suddenly teleport you through the wall into the black void outside the map. Absolutely game-breaking, deeply embarrassing, and completely mystifying.
The cause ended up being one of those things that's obvious only afterward. When the player overlaps a wall, my code pushed them back out based on their movement direction. But if you're sliding along a wall, your movement toward it is zero — and my push-out logic, fed a zero, cheerfully ejected the player out the far side. The fix is to push toward the nearest face of the wall, always, regardless of movement. One line, basically. Finding it was two days.
The fix I actually trust isn't the line of code, though — it's the test I wrote after: a fake player that rams the wall from twenty-four different angles, a hundred steps each, asserting it never ends up inside. That test has since caught two regressions I would have shipped.
There was also the enemy who became immortal. Enemies in Mech Escape are leashed to their camps — wander too far chasing you and they give up, walk home, and heal (so you can't cheese them across the map). While returning, they're immune to damage. Reasonable! Except my grounded enemies collided with walls, and a returning enemy walks in a straight line, so an enemy leashed on the wrong side of a wall would wedge against it. Forever. Immune. Just standing there in a hallway like a haunted appliance. The fix is what every RPG has quietly done since the beginning of time: returning enemies ghost straight through geometry. There's a reason the classics do it.
The bug that deleted my world (and the test that vanished)
One more war story, because it changed how I test.
While refactoring my world data, I ran a find-and-replace that had a subtle flaw, and it doubled every district's ID number — district 1 became 11, 2 became 22, 11 became 1111. The result: eleven of my twelve districts silently lost every wall, camp, and prop. And here's the horrifying part — the game looked completely fine. Floors still drew. The player still walked around. Screenshots looked plausible. The world was hollow and nothing visibly complained.
I had a test that would have caught it. It crashed instead of failing — and it turns out a crashed test disappears from Xcode's "Executed N tests" summary entirely. The count said 3 tests, everything passed. It took me an embarrassing number of theories (stale build? broken test discovery? cursed scheme file?) before I noticed the log line where a test started and never finished. Now I diff started-lines against finished-lines and never trust the count. Write that one down.
Designing for months, not minutes
The part of this genre nobody sees is the math. What makes Alien Invasion work over months isn't the combat — it's that the growth curve is tuned so there's always a next thing at a believable distance.
I didn't trust myself to tune that by feel, so I wrote a simulator: a little script that plays a full year of Mech Escape in a few seconds — 45 minutes a day, no purchases, upgrading greedily. First version of my economy? The simulated player finished everything in nine days. Nine days! I'd have shipped a weekend game and never known.
After a lot of curve-bending, the sim says: max chassis tier lands around day 53, the map fully opens around day 101, and after a full simulated year there are still 827 of 1,311 upgrade ranks left to buy. Growth rides three overlapping curves — your tier, your gear, your territory — so whenever one slows down, another is moving. Retention isn't something you hope for. It's something you design, on purpose, with a spreadsheet and some shame.
Art, by someone who can't draw
I cannot draw. This felt disqualifying for most of the project, and the Unity-era screenshots show me trying to hide from it behind asset-store textures.
The answer, for me, was to stop trying to draw and start trying to specify. All of Mech Escape's art is generated by a few hundred lines of Python I wrote — a little grammar of robots (a body, a head, some eyes, legs or a hover glow, optional shoulder pods, optional crown for the scary ones) and a palette system where every district owns a hue and the floors get darker the deeper you push. The player has five evolution forms from the same grammar, ending in a gold chassis that leaves a golden afterburner trail when it sprints.
The thing generated art buys you isn't speed — it's agreement. Every robot, floor, wall, and icon comes from the same tokens, so they can't drift apart the way my Unity-era art did. When a screenshot looked wrong in June, I had no lever to pull. Now the lever is a constant in one file.
Juice is a discipline
These past few months have mostly been what game developers call juice — the feedback layer that makes numbers feel like impacts. Damage numbers that pop and pile up. A range ring under the player that is your real attack range (grounded enemies need line of sight; flyers can be hit over walls). A floating joystick that spawns wherever your thumb lands. Enemy wind-up telegraphs. Little orange chevrons that hug the screen edge and point at threats you can't see yet.
My process for all of this became weirdly specific: I screenshot the game constantly — the build pipeline literally captures the game playing itself and checks pixels in the images — and for every frame I ask one question: would a stranger scrolling past this stop? For weeks the honest answer was no. Then one night the tier-50 fan fired all ten projectiles in a gold spray over a magenta district and I just sat there looking at it. That screenshot is the one at the top of this post. That was the night this stopped feeling like an experiment.
Where it's going
Mech Escape is heading to TestFlight next, and then, if the real-thumbs feedback doesn't humble me too badly, the App Store. Two years ago this was a shower thought about a game that stopped updating. Now it's twelve districts, five evolution forms, a year-deep upgrade economy, and a folder of screenshots I'm actually proud to post. There's a mountain still ahead — sound design depth, more bosses, live events worth logging in for — and honestly, that mountain is the point. The whole reason this game exists is that someone else's mountain stopped growing.
If you're one of the Alien Invasion faithful who kept checking for updates that never came: this one's for us. I'll be posting builds, numbers, and the inevitable postmortems right here on jcreates.dev.
— Josh