There’s something very different about starting a game project and actually seeing that game sitting on the Nintendo eShop.
Project City started with a relatively simple idea: I wanted to make a top-down open-city game where you could drive around, cause some chaos, make money, get chased by the police, and generally decide what you wanted to do.
Basically, I wanted to capture some of that chaotic fun I remember from older arcade-style open-world games, but on a smaller scale that I could realistically build myself.
And like most software projects, the idea sounded a lot simpler before I actually started building it.
The Original Idea
The core concept behind Project City was always pretty straightforward.
Give the player a city.
Let them drive around.
Give them different ways to make money.
And then give them plenty of opportunities to make very bad decisions.
Taxi jobs, package deliveries, food deliveries, gangs, weapons, ATM hacking, police chases, wanted levels, roadblocks, spike strips, drifting—the list kept growing.
That’s one of the first things I learned while developing the game:
It’s really easy to say, “You know what would be cool?”
It’s considerably harder to stop saying it.
Every new system creates another system that interacts with it.
If the player can commit crimes, you need police.
If you have police, you need wanted levels.
If you have wanted levels, you need police chases.
Now you need roadblocks.
Then spike strips sound cool.
Then suddenly you’re working on something you hadn’t even thought about when you started.
That’s game development.
Making a City Feel Alive
One of the challenges was making the city feel like more than just a map the player drives around.
I wanted traffic.
Pedestrians.
Businesses.
Police.
Things happening around you.
Places to enter.
Jobs to do.
None of those systems necessarily sounds enormous by itself, but put all of them together and suddenly there are a lot of moving pieces.
And because Project City is intentionally a smaller game, there was always a balance between adding more and actually finishing the damn game.
That’s harder than it sounds.
As a developer, there’s always another thing you could improve.
There’s another feature you could add.
There’s another edge case you could fix.
Eventually, you have to decide that what you’ve built is a game and actually ship it.
Bringing Back a Little of That Old-School Arcade Competition
One thing I really wanted Project City to have was that feeling you used to get from old-school arcade games.
You’d walk up to a machine, see somebody else’s initials sitting at the top of the leaderboard, and immediately think:
“Yeah, I can beat that.”
That little bit of competition could keep you playing the same game over and over again.
That’s a big reason I wanted leaderboards in Project City.
I didn’t necessarily want people to play through something once, reach the end, and never touch it again. I wanted players to look at someone else’s score and think they could do better.
Maybe you make a little more money.
Maybe you survive a little longer.
Maybe you find a better strategy.
Maybe you’re just determined to knock somebody else off the top.
There’s something incredibly simple about a leaderboard, but I love what it can do to a game. Suddenly you’re not only competing against the game—you’re competing against everyone else playing it.
And that old-school arcade mentality influenced more than just the leaderboards.
Why Project City Looks So Retro
The retro look of Project City was very intentional.
I wanted the game to feel like something that could have existed in an arcade, while still having modern systems and a larger city to mess around in.
That also influenced how I approached the graphics.
Project City isn’t built around a collection of traditional image-based graphics and sprites. A lot of what you’re looking at is actually being created through code.
Shapes, objects, effects, UI elements and pieces of the world are drawn and constructed programmatically rather than relying on a huge library of image assets.
Part of that was a technical decision, but it also became part of the game’s identity.
There are limitations when you work that way, but limitations can sometimes create a style of their own.
Instead of trying to make Project City look realistic, I leaned into it.
Simple shapes.
Bold visuals.
An intentionally retro presentation.
It started to fit perfectly with the arcade-inspired gameplay I wanted from the beginning.
And there’s something I really like about knowing that when you’re looking at the city on screen, you’re not simply looking at a bunch of artwork that was imported into the game.
The game is actually drawing that world for you.
For a programmer making a game, that’s just really cool.
Then There’s the Goat…
Somewhere along the way, Project City also ended up with Park Goat.
Because apparently what my crime sandbox really needed was a goat.
Park Goat became one of those parts of the project that I probably had way too much fun with.
It eventually developed its own personality, ridiculous situations, and plenty of stupid little jokes.
And that’s something I really enjoyed about making Project City.
Not everything had to be serious.
Sometimes an idea exists because it makes me laugh.
If I think something is funny or entertaining, there’s a pretty good chance I’m going to try putting it into the game.
Honestly, some of those smaller stupid ideas ended up being among my favorite parts of the project.
Developing for Nintendo Switch
Then came another major goal:
I wanted Project City on Nintendo Switch.
There’s something surreal about developing something on your computer for months and eventually seeing it running on an actual Nintendo console.
I’ve played Nintendo games for years.
Now there was something I made running on one.
That was pretty damn cool.
Console development also changes the way you think about your game.
Performance matters.
Memory matters.
Controller behavior matters.
UI that looked perfectly fine sitting two feet away from a computer monitor suddenly needs to make sense when someone is playing from across the room on a television.
There are certification requirements and platform-specific problems you don’t necessarily encounter when you’re just building something for PC.
It was a learning experience.
It could also be incredibly frustrating.
But seeing Project City actually appear on the Nintendo eShop made a lot of that frustration worth it.
Shipping the Game Wasn’t the End
Something else I learned?
Making the game is only part of making an indie game.
Then you have to convince people that it exists.
Screenshots.
Trailers.
Store descriptions.
Social media.
Reviewers.
Marketing.
Trying to figure out what actually gets people’s attention.
You can spend months—or longer—building something, release it, and then realize you’re competing with an absolutely enormous number of other games for someone’s attention.
That has probably been one of the biggest lessons from Project City.
Shipping a game and selling a game are two completely different problems.
And I’m still learning the second one.
Would I Do Things Differently?
Absolutely.
There are technical decisions I’d change.
There are features I’d approach differently.
There are things I’d prioritize earlier and others I’d probably cut.
But that’s also the benefit of actually finishing something.
You can watch 100 hours of game-development videos.
You can read books.
You can build prototypes forever.
Nothing teaches you quite as much as going through the entire process and eventually saying:
I’m shipping this.
Then real people get to play it.
And real people will absolutely find things you never expected them to do.
I’m Still Building
Project City wasn’t the end of my game-development journey.
If anything, actually releasing it made me want to keep experimenting.
I’ve got plenty of ideas—probably too many—and I’m constantly messing around with new mechanics, prototypes, and concepts.
Some will become games.
Some will probably sit unfinished on a hard drive forever.
That’s also game development.
But Project City will always be special to me because I got to go from:
“I think this could be a fun game…”
to seeing something I created available on a Nintendo console.
And that’s pretty damn cool.
