Hey there, I’m Jason a developer at Noodlecake. For the past 4 years I’ve been working on the publishing team, helping make other people’s games a reality. I’ve also been working on some side projects of my own. I’ve finally released one of them under our Noodlecake Labs brand, check it out on the Play Store and iTunes! It’s free!
It took a very long time to make this happen, and I learned some interesting things about game development while developing this simple game. I want to share some of those lessons with you, so let me take you back to where it all began. In June, 2014 I was hired as a developer on the publishing team at Noodlecake Studios. This was a big moment for me, as exemplified by this ceremonious tweet:
— Jason Knight (@00jknight) June 3, 2014
Since then, I’ve been a part of 50+ game releases across the Apple, Google and Amazon app stores.
I’ve also been delving into side projects (known as R&D within Noodlecake).
Sometime in 2014, I pulled up to a 4 way stop in snowy Saskatoon. I observed 3 cars ahead of me, mentally noted my place in line and awaited my turn.
“This could be a game!”, I thought.
“Probably could make it in a weekend.”
3 years later, that game is coming out.
What took so long? Well, a couple of things.
First, coding is hard. It always takes longer than you expect. The conventional software engineering mindset is to triple your initial estimate. I estimated a weekend. It took 3 years. Clearly something more sinister was at play.
Let’s diverge for a second and talk about a philosophy of productivity in game development. Here’s a pictogram demonstrating my thoughts on the subject:
A “good developer” would start at the center of the circle, and work outwards. First you make the core gameplay, then you polish it, then you make it beautiful, then you finish the product and SHIP IT!
The next image is to be read from bottom to top. Each line represents a batch of changes to the project and I’ve categorized them into the 4 color categories outlined above.
You can see that I started with the core gameplay. I made cube-based cars drive up to the intersection and stop, and you’d tap them to make them go.
Here’s what it looked like around that time:
EWW! It looks horrid! Get that away from me! That’s cause there hasn’t been any blue (art) commits yet!
The game is functional here. The “cars” have to come to full stop before you can tap them. If you tap them in the order they arrive, you get a point. Tap them out of order and it’s instant game over!
WOW! It’s a game! This white box prototype took me a weekend. But it looks terrible and it’s not fun. So what do we do now?
Well, I ran out of gameplay ideas, so I turned to art. Using only the “unity cube”, different diffuse materials and tons of scaling, I came up with this:
2 months and hundreds of cubes later.
This work is all “blue” – art work. No tweaks to the gameplay. It’s seductively fun working on aesthetics. You get immediate results and it’s a more linear “time->results” feedback loop than working on coding gameplay – especially when you don’t have any clear gameplay ideas and have to go through a long series of failures.
BUT, AND HERE’S THE POINT OF THIS ARTICLE:
Do your gameplay first.
Cause 3 month’s later I had this polished turd of a game:
This iteration looks great, but it’s not fun.
The gameplay hasn’t changed at all since the initial prototype. The cars still have to come to a complete stop before you can tap them, and users were quickly frustrated and quit playing. But hey at least it looks nice…
I’d been “user testing” this game with friends and family, and no one played this thing for longer than 1 minute. Failure was upon me. I had to return to core gameplay.
I put “core gameplay” at the center of the diagram above because everything else relies on it. And when you change it, everything else breaks. It’s like the fitted sheet around the mattress on a bed. There’s no way to change that sheet without screwing up the rest of the “well made” bed.
When you go back to change the gameplay, a lot of the art has to be redone. Especially the UI.
In the last year of 4 way stop, I tried about 5 different implementations of failure conditions. I tried a “red bar” that would build up over time to a game over state, and the only way to stop it was to tap the correct car. I tried a lives system. Then I moved the red bar around. Then I built the red bar into the road. Each of these attempts required a new UI and rendered the old UI worthless. Ugh.
After tons of user testing I came to an obvious conclusion: car crashes are exciting. Fake ones anyways. I leaned into that and settled on these rules:
– Cars pull up to a 4 way stop
– They stop at the stop
– Tap the cars in the order they arrive (or will arrive – if you tap early)
– Correct taps score a point and increment your combo
– Incorrect taps cause both the tapped car and the correct car to go simultaneously
– If they crash you lose!
Here’s what the released game looks like. It still isnt perfect but that is what Noodlecake Labs is for. A place to bring ideas and concepts to life like this.
This article is meant to teach you something about game development. Specifically about polishing too early. I’m gonna close this out with an analogy:
There’s no point making the bed if you still have to change the sheets.