DOOM DELIVERY / DEVELOPMENT LOG
DOOM DELIVERY After the Jam — What Comes Next
What player feedback taught me, why the bike controller is worth building on, and the next steps beyond the jam prototype.
Originally published on itch.io ↗. Reproduced here from the original post.
Godot Wild Jam #97 is officially over.
DOOM DELIVERY finished #93 overall out of 162 entries, with its strongest results in Fun (#55) and Theme (#58).

I’m happy with that.
But the rankings honestly aren’t the most useful thing I got out of the jam.
The feedback was.
One thing became pretty clear after watching people play and reading the comments:
The part I cared about most seems to have worked.
People noticed the momentum.
They learned that bad turns cost them speed. They started figuring out routes. Some replayed specifically to improve their score. And the weird Q/E pedaling controls, which I fully expected people to hate, ended up being one of the things several people remembered most.
That’s enough for me to keep going.
The jam version is a prototype
The current version of DOOM DELIVERY is basically one mechanic wrapped around one objective:
You have three minutes.
Make as many deliveries as possible.
For a jam, that worked.
I don’t think that’s enough for the full game.
I’ve been thinking a lot about the games I spent absurd amounts of time playing growing up: Tony Hawk’s Pro Skater, Mat Hoffman’s Pro BMX, and that whole era of short-session arcade games.
Those games gave you a timer, dropped you into a map, and then let you decide what mattered during that run.
That’s the direction I want DOOM DELIVERY to move toward.
Deliveries will still matter.
But I want them to become one thing you can choose to pursue, alongside challenges, collectibles, shortcuts, score goals, and other things scattered around the map.
The timer stays.
The freedom inside the timer gets much bigger.
Player skill should be the progression
I also don’t want the answer to progression to simply be:
Bike goes 5% faster now.
The thing I like about the current controller is that getting better already matters.
You learn how to build momentum.
You learn when braking is worth it.
You start recognizing better lines through the environment.
Eventually I’d like map knowledge to matter just as much.
Finding a shortcut or learning how to carry enough speed through a particular section should be more valuable than unlocking +10% acceleration.
The player should be the thing getting upgraded.
What needs work
There’s also plenty that didn’t work.
The game does a pretty bad job explaining itself.
Several players understood the bike before they understood what they were actually supposed to be doing.
The environments are extremely bare.
The art is prototype art.
The apocalypse mostly exists in the premise instead of the world.
And some players bounced off the controls entirely.
None of that surprised me much, but seeing the same things come up repeatedly made it pretty obvious where the next work needs to happen.
So what’s next?
I’m breaking development into a few broad phases.
First:
Clean up the prototype. Better onboarding, clearer objectives, better feedback, and another pass on the bike controller.
Then:
Expand the game loop. Deliveries, challenges, collectibles, shortcuts, scoring, and other reasons to explore the map.
After that:
Build an actual world worth learning. Routes should matter. Terrain should matter. Knowing the city should become part of getting good at the game.
Then:
Presentation. Art, animation, audio, effects, environments, and a much stronger sense that the world is very much ending around you.
And finally:
Content, balance, accessibility, polish, and everything else involved in turning a prototype into something I would actually feel comfortable releasing.
I’m deliberately not attaching a release date or promising a giant feature list yet.
I learned enough from the jam to know I want to keep building it.
Now I need to find out exactly what the full version wants to be.
For now, though:
The world is still ending.
There are still packages that need delivering.
