Tuesday, August 15, 2017

Mobile Game Lesson - Rapidly Responding to Change

I’m slightly embarrassed to admit that the mobile game I play the most is Solitaire.  Solitaire is a great game to play when you are waiting to board an airplane or when trying to fall asleep in a hotel.  I do both of those things quite often.

The first mobile Solitaire game I played had great graphics and some good features.  It also did a few things that annoyed me such as having slow animations when “undoing” moves and not having a feature that quickly completed the hand once all cards were exposed (a Solitaire hand is "solved" once all cards are face up),

Then one day, after Apple upgraded iOS, the game just kept crashing on startup.  This kept up for a few days.  Because I was traveling that week, I was having some serious withdrawals.  So I ended up trying a few competitive Solitaire games and finding one that not only worked with the latest iOS, but also had fast undo animations and the autocomplete feature.  I ended up buying that game and never going back.

By chance, I ended later ended up working with the studio that made the original game and was able to meet the small team that was supporting it.

It turns out that the team were unaware of how the market perceived this very profitable game of theirs or what the competition was doing.  Part of the problem was having a very deep feature development pipeline that didn't respond to change very well.

It was an eye-opening experience that such a simple game could suffer from the problems that larger games could as well.  The mobile game market can be very fickle.  Crashes, exploits or the emergence of a similar game doing something better can change you market overnight.  You need to be able to have some bandwidth set aside to deal with them.  Plan on change!