Thursday, December 29, 2016

Christmas Projects

Christmas holiday time is a great time to relax and take your mind of work or school.

It's also a great time to look into  new hobbies, read new books, learn new stuff or catch up on those TV shows and movies that you may have missed out on.

One of the things I love to do is to use the time to work on a small project. The original TY the Tasmanian Tiger game began as a Christmas project way back in the early 2000's. I did the initial prototype programming while Steve Stamatiadis did the art for the in game characters including TY. But that's a blog post for another time!

This year I got a Sphero BB-8 for Christmas and my son got a Force Band to use with his Ollie that he got last Christmas. The Force Band works amazingly well with both the BB-8 and the Ollie. Being able to control your droid using simple hand gestures is the closest feeling you'll get to using the Force. It truly is amazing.

Being a huge fan of the Apple Watch I decided to start a Christmas project to make my own Force Band for my Watch.

The Sphero SDK is freely available for all platforms and is fairly simple to integrate into an iPhone Xcode project.  I found a great sample project from Robotics Trends that used the Watch's accelerometers to control a Sphero. This is a great entry point!

Trying out different control methods for BB-8 with Apple Watch
However I decided to start fresh and explore some other input methods that the Watch offers.

I tried using buttons and swipe controls to move BB-8 - all of which work okay, but the one I found interesting to explore is the use of the Digital Crown as a steering wheel.

This actually feels great having BB-8 move while rotating the crown to steer the little droid. I have a few extra features to add, such as a simple way to slow down and speed up the droid - and the UI could use a little love :-) 

Speaking of which,  I better get back to my Christmas project so my son and I can take our droids on adventures with the Force Band and Apple Watch.

I hope you all have a happy new year!

- Johnno

Friday, December 16, 2016

Making Snappy Word

Snappy Word just relaunched exclusively on the App Store.
You can get it here!

I originally made Snappy Word at Right Pedal Studios as a launch title for the Apple Watch. When Right Pedal wrapped up the game was removed from the App Store. However Steve Baxter (visionary investor, awesome guy and a great boss) was kind enough to let me have the game IP.

I planned to relaunch the game as at it was but Apple had released some cool new stuff with Swift 3, WatchOS 3 and the new iMessages app ability. So I decided to do a major overhaul.

I rewrote a lot of the code to be in Swift 3. I updated the WatchOS version to use WatchOS3 and run as a seperate app without the need of an iPhone. I added an iMessage app extension so the game could be played within iMessage against friends.

The original version had a multiplayer element that used Game Center. This never worked well as Snappy Word is a very niche game and the multiplayer required you to find someone online at the same time also looking for a match. Finding someone to play against was like trying to find a needle in a haystack, so moving the multiplayer element into iMessages and making the game turn based was a no brainer.

The original art had an angular look to it to help it stand out from other tile based word games. This art was done by the talented Rupert Lewis Jones:

The original main menu screen with angled tiles.

The Watch version actually had rounded tiles so I decided to embrace that look in the iPhone version to maintain consistency. I also converted a number of options from words into icons. Most mobile game players understand the iconography of leaderboards, settings and play images.

The new look main menu screen with rounded tiles and icons.
I also updated the game screen to use the rounded tiles.

Original Snappy Word game screen.
New Snappy Word game screen.
In the original game I used interstitial pop up ads that appeared after every 3 play sessions. These were invasive and broke the game flow. So with this update I added an AdMob banner to the top of the screen and removed the interstitials.

I felt this was a good compromise to keep the game free and have some monetisation while not being in the players face. If they really hates ads then they have the option to spend 99c to remove them.

I did some minor rejigging of the Watch graphics, but the biggest improvement came in terms of a speed boost from switching to WatchOS3. The game responds really well to the button presses, something that was a little slow in the previous WatchOS version. I also included GameKit so it didn't need to rely on the iPhone to get and set high scores.

There were a few things I would love to have spent more time on, but the reality is that this sort of game won't set the world on fire in terms of sales so there was a practical limit on the time I could  spend on it. As it was I spent more time than I had planned as learning Swift3, WatchOS3 and the iMessage framework took a lot of effort.

I used swipe controls to select letters on the iPhone version but relied on button presses for the iMessage and Watch versions. To get swipe working in these would have required a few major changes that I couldn't justify in terms of time. It is a little jarring to have two different input styles, and as a designer I know it should be all the same - but given the constraints and my belief that people will probably only play on one platform, ie. iMessage only, or Watch only, I don't think it's too big an issue. If people demand it, I will fix it in a later update :-)

The awesome tutorials from Ray Wenderlich were invaluable in helping me learn the skills necessary to make this game.

My main resources from Ray Wenderlich were:

iOS 10 by Tutorials - Helped me build the iMessage app extension
WatchOS by Tutorials - Got me up to speed with WatchOS3
2D Apple Games by Tutorials - Helped me with Swift3 and SpriteKit

The game has done well on launch and has been featured in the app and iMessage games sections of the App Store around the world.
Featured in New Games We Love

So far it's been featured in over 97 App Stores which is not bad for a game that is targeted at English speaking players.

Also featured in the iMessages App Store
Now, with Snappy Word done it's full steam ahead on my next game, the 3D action racing game called Billy Carts that I'm making with the awesome Pete Mullins. This is an Aussie game featuring outback landscapes, Aussie animals and lots of destruction! 

I'll be blogging about it's development over the coming months so please check back with me to see how it progresses.


Monday, December 12, 2016

Billy Carts Dev Blog 13 December 2016

Yesterday I caught up with the talented Pete Mullins, my co-conspirator on Billy Carts, so we could go over what we've done so far in the game, and more importantly, plan what we have yet to do.

Like many indie game projects Pete and I are working remotely on this one using Trello, Unity Collab, email and Google Drive to share assets, ideas and documents. So it's great to catch up in person every now and again!

As a result of our meeting we worked out that our first priority is making sure the game controls well and feels fun. Pretty obvious really :-) We're not too worried about the overall design just yet - we're fans of iterating rapidly on ideas to see if they work or not and letting that shape the game. Definitely not the approach I would take on an adventure game, but with fast action games it's all about the moment to moment feel.

Yesterday was also a great opportunity to get some first pass assets and integrate them into the game.

We're aiming for a very Australian theme with Billy Carts pulling inspiration from where we live. So I expect a few of my Aussie friends will cringe when they play the game. Make them squirm, I say!

Some of the new assets Pete built include a petrol can (or gas can for Americans) and a coin.
Collectable coin featuring a koala!

A petrol can that refills your billy cart.

Technically Billy Carts are box carts and don't have engines that require petrol/gas - but this is a game and we're prioritising fun over facts :-)

If the game has a positive reception and we're lucky enough to keep building on it post release, we're definitely keen on adding new environments inspired by other countries - particularly some of the beautiful scenery from the USA. So fingers crossed it does okay!

One of the new assets we added in during our catchup was a sharp right turn in the track. It sounded like it would be fun on paper but in practice it slowed down the game play - so we nixed it.

The track is  made up of small segments that are each unique in their shape and include small hairpin curves, dips, hills, etc. and this seems to work well.

So, the next step is to wire up the new assets, see how they feel and tweak them. This is a process we'll be repeating until done, so stay tuned to see where we end up.

Coins in the game!

Thursday, December 08, 2016

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.

Monday, December 05, 2016

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.

Friday, December 02, 2016

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 :-)

Saturday, May 21, 2016

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 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.


Saturday, May 07, 2016

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 :-)