DETOUR / DEVELOPMENT LOG
Day 5: How to Make Progress Without Burning Out
Building varied road hazards with shared mechanics, making steady progress, and knowing when to stop during a game jam.
Originally published on itch.io ↗. Reproduced here from the original post.
Game jams make it very easy to convince yourself that every available hour should be spent making the game.
There is always another feature.
Another bug.
Another piece of art.
Another system that could use one more pass.
And when the project is going well, that pressure can actually get worse because you’re excited.
That was basically where I found myself on Day 5.
I didn’t have a huge development session today.
And I’m okay with that.
A Small Day Is Still a Development Day
After yesterday’s lighting overhaul, DETOUR was in a much better place visually.
Today I wanted to start replacing some of the obvious placeholder hazards with objects that actually belong on a dark highway.
The existing obstacle was still basically:
red rectangle = bad
Functional.
Not exactly atmospheric.
So, I started building a small set of hazards that can all use the same underlying collision and damage logic while looking completely different on the road.
The important part is that I’m not adding four new gameplay systems.
I’m adding visual variety to one system that already works.
That distinction matters a lot in a short jam.
Reusing Mechanics Instead of Inventing More
The obstacle spawner already had lane logic designed to keep the road reasonably fair.
Rather than throwing that away, I changed the system so it can choose from a collection of obstacle scenes.
Conceptually, it went from:
@export var obstacle_scene: PackedScene
to:
@export var obstacle_scenes: Array[PackedScene]
The game still:
- decides which lane the next hazard should use,
- keeps lane changes within a reasonable range,
- spawns the obstacle,
- lets the existing collision code handle the rest.
The only new question is:
Which obstacle should appear this time?
That’s a very cheap way to make the road feel less repetitive.
I also kept the tutorial obstacle separate from that random pool.
The first obstacle exists to teach the player how to steer.
That means it should stay predictable.
Randomness is useful during normal play.
It is not automatically useful everywhere.
Building a Construction Barrier
The first new hazard was a construction barrier.
I built it entirely from simple polygons:
- dark frame,
- orange reflective section,
- white reflective section,
- two supports,
- one collision shape,
- one light occluder.
No texture assets.
No external art.
Just geometry and lighting.
Once I put it on the road, the headlights did most of the work.
From far away, it sits mostly in darkness.
As the car approaches, the reflective panels become readable.
The barrier also casts a soft shadow using the same lighting system I built yesterday.
It immediately felt more believable than the red block.
More importantly, the silhouette is completely different.
That means the player can start recognizing hazards by shape instead of just color.
Building a Pothole
The second hazard was intentionally the opposite.
The barrier stands above the road and announces itself.
The pothole should be easy to miss until the headlights catch it.
So, I built it from two irregular polygons:
- a slightly lighter broken asphalt edge,
- a very dark center.
No glow.
No shadow caster.
No giant visual marker telling the player:
HERE IS THE GAME OBJECT.
It is just a dark shape on a dark road.
As the car gets closer, the outer edge becomes much easier to read.
That gave me exactly the progression I wanted:
suspicious dark patch → wait, that’s something → oh, that’s a pothole
The collision shape is also smaller than the visual shape.
I want the player to be punished for driving through the middle of it, not because one pixel of the car touched the outer edge.
Then I Started Building Debris
The third hazard was fallen debris.
The goal here was another completely different silhouette:
- diagonal,
- irregular,
- messy,
- something that looks like it ended up in the road rather than being deliberately placed there.
The first version already works mechanically and visually.
It also casts a shadow.
A very dramatic shadow.
And that’s where I stopped.
The debris still needs a little cleanup.
The pieces need to be grouped slightly tighter, and the occluder should probably be smaller so the shadow doesn’t become more visually important than the object casting it.
Normally, this is the moment where I would be tempted to say:
I’ll just fix that one thing.
And then:
Well, while I’m here…
And suddenly it’s another hour.
Knowing When to Stop Is Part of the Work
Game jams are exciting.
That’s part of what makes them fun.
For a short period of time, you have permission to obsess over one weird little project.
You wake up thinking about it.
You think about it at work.
You think about mechanics while driving.
You want to get home and immediately open the engine.
That energy is useful.
It can also trick you into thinking rest is wasted time.
It isn’t.
If I’m exhausted, I make worse decisions.
I miss bugs.
I overcomplicate things.
I spend 45 minutes solving a problem that I probably could have solved in ten the next morning. And eventually the project stops being fun.
There is always more game to make.
There is only one person sitting at the keyboard.
Taking care of that person is part of finishing the game.
You Don’t Have to Maximize Every Day
Today wasn’t a giant breakthrough day.
Yesterday I transformed the whole visual identity of the game with darkness, headlights, illuminated signs, shadows, and the warm light at home.
Today I made:
- a construction barrier,
- a pothole,
- a first pass at fallen debris,
- a randomized hazard pool,
- and a few small code cleanups.
That’s enough.
Actually, that’s more than enough.
One of the easiest traps in a game jam is judging a day by how dramatic the changelog looks.
But consistency matters more.
A small amount of good work today means I still have energy to do better work tomorrow.
And tomorrow happens to be a shorter work day heading into the weekend.
I’ll have more time.
I’ll be more rested.
The debris will still be there.
Building in Public
Another thing I’ve been enjoying during this jam is documenting the process outside the game itself.
These devlogs have become a kind of second project running alongside DETOUR.
I’ve also been sharing development clips, screenshots, experiments, and updates elsewhere.
If you’ve been following along here, you can also find the project in a few other places:
- DETOUR on itch.io: https://ryanpond.itch.io/detour
- Website: ryanpond.com
- X / Twitter: x.com/ryanpondbuilds
I’ve been watching the numbers on these posts as the jam progresses, and one thing has become pretty obvious:
The posts that promise to explain how something was made seem to attract more attention than posts that simply say what I made.
That’s useful information too.
A devlog can be more than a diary.
It can be documentation.
It can be a small tutorial.
And hopefully it can give somebody else working on their own game an idea they can steal.
Day 5 Takeaway
Today’s technical lesson was:
You can create a lot of variety by changing presentation without changing mechanics.
The barrier, pothole, debris, and original obstacle all use essentially the same gameplay system.
They just create different visual problems for the player to solve.
But the more important lesson today was simpler:
Rest is part of development.
I don’t need every day of this jam to be a marathon.
I need enough good days to reach the finish line.
Tomorrow I’ll clean up the debris, playtest the full hazard set, and keep moving.
Tonight I’m going to stop.