For 22 years, Nuts and Bolts Web Design has built websites and kept systems running for other people. Now I’m building something of my own: Cul-de-Sac Crew™: Suburban Survivor, a game about a neighborhood crew taking back their block. I’m going to use this blog to share what goes into it, the business side and the tech side, the same way I’d walk a client through a project.
This first post covers the update I just finished. It took three builds and a few long days. Here’s what I built, and why I built it the way I did.
Start with the player, then the business
The headline feature is revives. When you go down, the game offers to bring you back. You get 2 per run, back up with 60% health and 8 seconds of protection.
That sounds simple. The decisions behind it weren’t.
Revives are also how the free versions of the game will pay for themselves. On the browser and Android versions, a revive will cost a short ad, and only if you choose to watch it. I had to decide what happens in every case before writing a line of code:
- The player watches the ad: they get the revive.
- They close it early: no revive, and they’re back at the offer to decide again.
- There’s no ad available: they get the revive free. Running out of ads is the ad network’s problem, not the player’s.
- They’re running an ad blocker: no revive, and a friendly note explaining that ads keep the game free, with a link to support the game directly.
- They bought the game on PC: free revives, no ads. They already paid.
- They’re playing the free demo: free revives, no ads, ever. The demo’s job is to show the game at its best.
That last one was a late call. The demo didn’t have revives at first. Then I watched the effect in action and decided it’s one of the best moments in the game. Hiding it from the people deciding whether to buy didn’t make sense.
The point for any business owner: write down every path before you build. The edge cases are where trust gets won or lost.
Make the moment count
A revive shouldn’t feel like a menu. When you get back up, your crew member blasts out a ring of pixels in their own dash colors, the crowd gets shoved back, and the screen hits with a new shock wave: a zoom punch, one thump, then a rolling wave. I made it different from the game’s other screen shakes on purpose. Your eyes and your gut should both know something big just happened.
No accounts. Ever.
Every game runs into the same question: how do players move their progress from one computer to another? The usual answer is accounts, with logins, emails, passwords and a database of player info to protect.
I didn’t want any of that. This game is made for all ages, kids included, and the safest data is data you never collect. So I built Save Codes instead. The game packs your progress into a code. Copy it, paste it somewhere else, and you’re back. The code holds progress and settings only. No name, no ID, no date. The same save always makes the same code, so nobody can track anyone with it.
I also built in the safety nets I’d want as a user. The game shows you what’s in a code before loading it, backs up your current save first, and gives you an UNDO button. Every one of those came from asking “what’s the worst thing that could happen here?”
Measure what matters, keep nothing you don’t need
The full game now sends anonymous stats when a run ends: stage, crew member, difficulty, how long the run lasted, how far it got and how smoothly it ran. No names, no accounts, nothing typed by the player, and the stats server doesn’t keep IP addresses. Each launch gets a random session number that’s never saved to the device. The free demo sends nothing.
The stats go to a small server I run myself, not to a third party. That’s my IT side talking. If I’m asking players to trust me with even anonymous data, I want to control where it lives.
The stats have already paid off. The first live data showed every field arriving exactly as designed, and I could see quits, revives and save code use come in from real play the same day the update went out.
Fix the bug players can feel
This update also fixed a bug I’m glad to be rid of. Right after the game’s safe opening, enemies started arriving about 3 times faster than designed, all the way to the 5 minute mark. It felt like hitting a wall at 30 seconds. It came down to one piece of logic attached to the wrong condition. On Rough Night difficulty, the board at 45 seconds went from about 124 enemies to about 68.
That’s a lesson I’ve seen in client work for two decades. When something feels wrong in use, it usually is, even when the code “works.”
Small things, done right
- Your crew member shows through trees, houses and cars as a colored silhouette.
- The HUD shows the difficulty next to the stage name.
- The mouse wheel scrolls help screens from anywhere, and Esc goes back on every menu.
- Every new line of text ships in all 16 languages the game supports.
None of these are headline features. All of them are the difference between a game that feels finished and one that doesn’t.
Hosting it myself
The full browser version lives at play.culdesaccrew.com, hosted by me instead of a game portal. That means I control the experience, the privacy and the support link you see on the title screen. Portals have their place. For a game I’m putting my name and my business behind, owning the platform was the right call.
What’s next
Android is in testing, and the Steam demo is on the way. In the next post, I’ll go deep on the work that went into keeping this game safe for kids, from how ads are requested to how the Privacy Policy and Terms match what the game actually does.
If you’re a business owner thinking about building something of your own, or you need help with your website or IT, you know where to find me.
Work hard and play harder.
