Gotta know when to hold 'em, know when to fold 'em, know when to walk away

Steve Jobs famously said "Focusing is about saying no."

I've been thinking about this quote a bit lately. Like many game developers I have a number of games I want to make. And like many game developers I've even started building some of these games.

I had been developing a prequel to my classic adventure game Flight of the Amazon Queen as an Apple Watch game. I love my Apple Watch and love adventure games. With titles like Lifeline doing well it seemed like an opportunity to do something in that space.

The game, creatively titled Return of the Amazon Queen, was shaping up to be an interesting adventure. I had the idea for it, and I said "Yes, I'm going to do this." In reality, I should have said no. The audience for adventure games lives on the PC. As much as I love my Watch, the audience for the game on the Watch was probably going to be me - and I already know how to solve all the puzzles!

Return of the Amazon Queen on Apple Watch

As well as the Amazon Queen prequel I had also developed a 2D endless runner in Swift. The game is 90% done, meaning the remaining 10% will take at least 90% of the time I already spent on it to actually wrap it up. It's the seemingly little things like ad networks, leaderboards, testing, etc. that take up way more time than people think.

A character from the endless runner made with programmer art!

While the game was fun to play (for me at least) it didn't get the reaction from family and friends that I had hoped for. They tended to play it for a bit then politely return the phone back, or switch to another game (never a good sign!). I could try and fix, but the reality is the style and mechanic, and the fact that it is 2D, are all factors keeping it from greatness.

So, I've folded these two games in order to focus on Billy Carts, a game that has already elicited more excitement from those I've shown it to than my previous efforts.

There is always that sense of duty to finish what you started, and that's a great thing to help you keep focused so you actually ship your game. But sometimes its best to put that game aside, write of the sunk cost of time and effort, and focus on the better idea.

The good news is that the time I spent on those two unfinished games only helped me become a better programmer and designer. I managed to get experience with some new frameworks that will carry over into Billy Carts.

Remember, even if you do say yes, it's okay to say no later and walk away if you really believe that that is the best thing to do.

Time is precious and as indie developers it's important to make stuff that isn't just okay but is great. We're doing this because we love what we do. We are fortunate that we're not a cog in a big publisher driven machine making some licensed game for a pay check. We're in control, and sometimes we may get a little out of control, but ultimately we have the power to say no and make things right.

You're never too old (or experienced) to ask for help

With the new game underway in Unity, I'm finding that I have a lot of new stuff to learn. I've been using Swift for the last year and now I'm learning how to program in C#. I can find my way around Xcode but now I need to find my way around the Unity IDE.

While the internet is an awesome resource full of tutorials, how-to-videos and code samples sometimes it can be a struggle to find the answer you're looking for.

If you find yourself hitting your head against the wall and are spending way more time than you should trying to solve a problem, then swallow your pride and reach out to other indies and ask for help. Most are cool and are more than happy to help out if they can.

Hopefully you'll get the answers you need and will be back making your game.

And don't forget to be on the lookout for others experiencing pain so you can pass on your newfound knowledge. It pays to pay it forward.

No matter what you do it will take a lot of work

I've just wrapped up an update to my iOS game Snappy Word. It's a word game built in Swift for iPhone, iPad, Apple Watch and iMessage.

Snappy Word

I originally wrote the game for Right Pedal Studios back when the Apple Watch came out. The game was one of the launch apps and I'm quite proud of being there at the beginning.

I was lucky to get Snappy Word assigned to me when Right Pedal wrapped up, so rather than ~re-releasing it I decided to do a major update. This meant making it work with Swift 3 and the latest WatchOS, adding in an iMessage version, redoing the art and adding in a new game mode.

Despite it being a fairly simple 2D word game the rewrite in Swift 3 and the addition of new frameworks ended up taking a few months of part time work to finish.

But I learned an important lesson doing this update:

No matter what you do it will take a lot of work.

I've already started my new game - a cool 3D game built in Unity with my mate and talented artist Pete Mullins.

Billy Carts made in Unity

The amount of work to get the initial 3D game up and running was probably a little less than it took for me to wrap my head around the iMessage framework. But showing the 3D game to friends got oohs and aahs. This was a "real" game.

This game is definitely a leap ahead of my previous stuff, and yes, it will take a lot of work. But you know what? I'm really looking forward to putting in that work because this time the effort is going to show on screen.

As I've learned everything takes effort so you might as well go for gold :-)

Learning To Be A Better Programmer

I have a confession to make. Despite being a game developer and having programmed lots of games, I've always considered myself a game designer rather than a game programmer.

The truth is there have always been way better programmers than me in the business. People who can squeeze every little bit out of a game engine or who can write faster, more elegant code. As a result I've always shied away from personally programming fast action games.

I made the original Halloween Harry on the Microbee in BASIC in the mid eighties. Writing it in assembly was beyond me so I designed the game around the limitations of BASIC and it ran fine.

Halloween Harry for the Microbee (1985)

In the early nineties I did the original prototype for the reboot of Halloween Harry in AMOS on the Amiga. It ran okay, but wasn't shaping up to be a game that could take on the world.

Thankfully the talented Rob Crane and Tony Ball took over the coding of the game engine and graphic engine respectively and made fast, slick code that brought Halloween Harry to life and landed us a deal with Apogee. I focused on design and level building for the remainder of the project!

When I did program, I chose games that didn't require high frame rates. Flight of the Amazon Queen was a leisurely adventure game that didn't rely on multiple levels of parallax scrolling or cutting edge particle systems. It was the sort of game that I felt comfortable building.

Flight of the Amazon Queen (1995)

I tended to focus on puzzles games too - Word Shake is an early example.

Word Shake (2005)

I followed this up with other puzzle/brain training games like Brainiversity, Smart Attack, Snappy Word, Stroop Attack and Brainiversity 2.

Even the more recent Save Our Village was designed to move at a leisurely pace, focusing on town building and exploration.

Save Our Village (2016)

But now, with great tools like Unity3D and XCode and languages like C# and Swift I have the opportunity to work with high level programming languages that also produce lightning fast code.

And  thanks to the internet and the many excellent programming resources like raywenderlich.com I am learning a lot more - and doing it faster and easier than ever before.

In fact, I now think of myself as a game designer AND game programmer.

I reckon I've earned that.

-Johnno

Revisiting Old Games In Development

Like every game developer I have a lot of game ideas.

Most are ideas jotted down in notebooks, on scraps of paper or as notes on my phone. Sometimes the ideas progress to prototypes on the computer/smart phone to test out. It's here where I find out that some ideas are better left as just ideas.

I also have a few games that I've built out to a reasonable level of completion - but not released. There are many reasons for not finishing them. Sometimes they aren't working, other times the market has shifted and they don't make sense to pursue, and other times better opportunities take precedence.

I have a playable version of a text adventure game called Return of the Amazon Queen on the iPhone and Apple Watch. It's designed as a paid game, but sadly the market for paid games has really dried up - at least on mobile. So this game has been shelved until I can work out a way to make a story driven text game work as free to play.

Return of the Amazon Queen

Another game I developed to almost completion was a simple endless runner. I shelved it when I struggled to find a way to make it compelling beyond just a few days of play.

Endless Runner

That's the problem with quick twitch games - they need a meta game to engage the player beyond the initial thrill of play. There are so many free games competing for players attention that a game needs a reason to come back. Crossy Road does a great job with the overall Pokemon/Skylanders collection mechanic of engaging the player's desire to want to collect every character and thus re-engage in the game.

It became obvious that building out such a mechanic was a big job and was at odds with the idea of quickly developing a fast twitch game  The core game could be produced quickly, but the meta game (especially for sole developer) could take a lot of time. With that realisation I put the game on hold.

I've just finished a huge update for Save Our Village, a free to play game that has good retention, a strong meta-game and a monetisation system that works . As a result I've got time to go over some of my old shelved games to see if a new perspective can help solve old issues.

I have some ideas on how to make a narrative text game work as free, and I've reconsidered ditching the meta game for the endless runner.

So for the next few weeks I may make some progress on either one of these two games... at least until Save Our Village launches and work begins on preparing the next update for that game :-)