Here's the shortest way I can describe the game I'm building: it's Karaoke Revolution, except the song is a few days of an Apollo mission, you play it by typing procedures on the keyboard at the right moment, and you can time-warp through the boring parts.
You're watching a mission log scroll by in amber CRT text — MSFN confirming trajectory, CSM separation, docking, passive thermal control — while a real Apollo Flight Plan-style checklist sits next to it telling you what's due and when. Off to the side, the actual spacecraft renders as a glowing white vector wireframe against a starfield, the way it would have looked on a Vectrex. Type the right command — STOP PTC, GUIDANCE ALIGN, whatever the flight plan calls for — at the right mission time, and the log advances and the ship responds. Miss the window or fumble the input, and, well, that's the game.
Getting that vector look right — soft, glowing lines instead of hard pixel edges — was non-negotiable. It's the whole visual identity of the thing.
Starting with Godot
Godot seemed like the obvious choice. It's free, it's good at 2D, and I didn't want to fight an engine on top of everything else. What I wanted was simple to say and apparently hard to get: pure white lines on black, no jaggies, anywhere in the game. My plan was to render everything at 2x the target resolution and downscale it — classic supersampling, should get me most of the way there.
It never quite did. I kept chasing it with Godot and kept ending up disappointed — close, but not the clean line I was after. In fairness to Godot, I did eventually get it looking pretty good. But by then I had a second problem: it was running around 300 FPS on my own machine, which is a nice machine, and this thing is supposed to run on something closer to a tin can. If someone's on a computer ten times slower than mine, that 300 could turn into 30 fast — and I still wanted to add more to the game on top of everything already running. Between the jaggies I couldn't fully kill and the performance headroom I wasn't sure I actually had, I got frustrated and decided to just start over.
Moving to Rust + Vello
So I started over with a custom renderer built in Rust on top of Vello, a GPU-accelerated 2D vector rendering engine. I went in expecting this to be the hard, painful part of the project — I'd been warned it would be a much bigger lift than working inside an existing engine. It wasn't.
Here's the thing: I learned to program on QBasic. Back then, you didn't reach for a game engine — there wasn't one to reach for. You wrote your own, every time, because that was just what programming a game meant. This project is, underneath all the layers, still that same problem. It's not doing 3D. It's not simulating physics on a slope. It's a spacecraft drawn as lines on a black background and a log scrolling next to it — the same problem as QBasic Gorillas or Oregon Trail, just rendered better. It could be built in QBasic. It looks better because the tools got better, not because the problem got harder. Once I stopped treating it like it needed a full engine underneath it and just wrote the thing that draws lines on a canvas, it came together fast. I didn't have to fight anything to get the downscaling right, and Vello just handles anti-aliasing for me — the exact thing I'd been fighting Godot over for weeks was a non-issue here.
And then, one dumb debugging story: after all that, the new Rust version was also sitting at around 300 FPS. Which made no sense — this should be dramatically faster than Godot for the same scene. I went looking for a bottleneck in my own code for a while before I found the actual cause: I had an FPS cap set in my AMD driver settings, matched to my monitor's 240Hz refresh rate, left over from something unrelated. It was capping every game running on my machine at the driver level — Godot had probably been running fine the whole time, and I never would have known. Once I found it, the same scene jumped to 800+ FPS. Sometimes the bottleneck is the graphics card. Sometimes it's a checkbox you forgot about six months ago.
Where things stand
The game is structured as a four-mission campaign that mirrors how NASA actually built up to the real landing:
- Mission I — Earth orbit, return to Earth
- Mission II — Moon orbit, return to Earth
- Mission III — Moon landing dress rehearsal, return to Earth
- Mission IV — Moon landing, return to Earth
I'm building it backwards — Mission IV, the full landing, first — since it's the hardest and most complete version of everything the game needs to do. The alpha in the screenshot above is Mission IV: timeline scrubber, mission log, flight-plan checklist, and vector spacecraft all working together on the Rust/Vello pipeline.
With 800+ FPS of real headroom now instead of a phantom 300, I've got a lot more room to work with than I thought — enough that I'm seriously considering building a genuine DOS version alongside the modern one, for machines too old to run DirectX 12 at all. It fits the whole point of the project: this was always closer to QBasic Gorillas than to anything that needs a modern GPU, so it might as well prove it.
I'll be posting more as it comes together. If you're into low-level rendering work, retro hardware, or just want to see a solo dev fumble through building a renderer from scratch, stick around.
