There’s a saying in Go, “lose your first 100 games quickly.” The idea is that you want to make mistakes early and often to work out the kinks of the game, get a feel for it, and fall into the common pitfalls so that you can avoid them in the future.
The same proverb applies to many things in life, even game dev. Besides a simple dice game and some demo’s I made for classic systems in high school, Impulse was my first real foray into game development. With a number of complex mechanics, 20 levels, and even an intro story cutscene, it’s pretty remarkable that I managed to get it out the door in 16 days. The game has garnered a humble 300 downloads and has a 5-star rating in the App Store.
The point wasn’t to break records or even to create a remarkable experience. It was a learning exercise, and any time there’s a deadline involved, falling into the common pitfalls, much like a game of Go, is inevitable. I got to see the whole lifecycle of a game from start to finish in a compressed amount of time. From concept, to napkin designs, to game engine choice, to art decisions, to first line of code, to shippable and playable, the journey was one of the most incredible learning experiences in my coding career to date.
Since I would consider the experiment a success, I wanted to share a few lessons learned that may help first-time developers ship their game on time.
Save your best idea
Your first game should be simple and achievable in a short time. Save your great idea for game number 3 or 4 when you’ve had a chance to get your feet wet with game design and development.
I’ve had an idea for a new kind of tower defense game for years now, but I have yet to start on it, because I know that it will be subject to feature creep, complex mechanics, and will likely take several months to implement even half the game’s unique gameplay. I’m saving it and building smaller games until I feel confident enough to embark on that journey.
Game engine choice is less important than you think
Since I was on a deadline and was already comfortable in Objective-C, I chose SpriteKit as my engine of choice. If I had more time I would have chosen Unity or Corona due to their cross-platform nature, but the deadline forced me to buckle down and get coding on day 3.
Engine choice is far less important than many people think. Much like a great film can be shot on a cheap DSLR, and a terrible film can be shot on Arri Alexa (forgive the brief former-filmmaker lingo), what engine you choose is far less important than the design of the game itself.
The important thing is this: Your first game should be made in whatever game engine is most approachable for you. Already know C# and want cross-platform? Unity is a great choice. Comfortable in C++ and want 3D? Check out Unreal. Know Swift or Obj C and only shipping to iOS? SpriteKit works fine.
Don’t worry too much about scalability
This is your first game, not your magnum opus. “Spaghetti code” is perfectly acceptable, as are imperfections. Make it work and don’t worry too much about scalability. You’re here to learn, and it’s more important to see the whole lifecycle of a game’s development than to make perfectly clean code.
I ran into an early problem in week 1 where my partner spent a lot of time trying to get SpriteKit’s level designer to work for us. Turns out it was incredibly buggy, and after 5 days on this problem we had to have a serious talk and ditch the visual level designer entirely. In an afternoon, my partner whipped up a simple coordinate-based level generator, and it worked like a charm for our purposes.
Although this solution wouldn’t scale for hundreds of levels, it worked fine for our target of 20 levels.
Demo early and often
As soon as you have a working alpha, get it into the hands of your audience. Players will give you valuable feedback and even suggest additional features. Now, you run the risk of feature creep and have to ignore vast swaths of these suggestions, but outside perspectives give you a fresh look at your game and help make it more approachable actually fun.
When I demo’d the game on day 7, I noticed people had trouble pulling back on the ship because the hit box was too small. It took less than an hour to implement the code that allows the player to pull back anywhere on the screen, and it permitted far better control over trajectory.
A work of art is never finished, only abandoned
Set a hard deadline for yourself and ship it on time. Just ship the damn thing. As soon as you have a working game that’s reasonably fun to play and has even just 10 minutes of content, ship your game. Once it’s out into the world you have the choice of iterating and adding mechanics and levels, or moving on to your next game. Once I had something imperfect but playable, I chose to ship move on, and I still think that was the right decision.
Set a deadline, start coding, and view it all as a learning experience.
You can check out my game, IMPULSE: The Journey Home, which is free in the iOS App Store.