Fast First, a Designer's Diary, Part 2

FirstPlayer.png

This is the second and last of multi-part article describing the design and development of Fast First.  If you haven't read the first part yet, you should.

When we last left Fast First, it was doing well in beta-testing, and about to run the gauntlet of Atlanta Game Fest.  Assuming it survived that, I was planning on releasing it right after the convention.

 “No plan survives contact with the enemy.” — Helmuth von Moltke.  

I don’t view my testers as the enemy. Really.  The app wouldn’t be what it is today without them.  However my plan did not survive.   The big feedback was the request for some type of animation.  In service of time-to-first-player, there was no animation.  If you tapped the re-randomize button, it just drew the new tables, as quickly as it could.  The same was true for any of the triggers for re-randomization.  Some users, however, didn’t like it.  They seemed not to have confidence that it was changing. 

Ugh.  Every designer faces this type of problem.  It doesn’t matter if you’re designing a board game software, or a piece of hardware. Users give you feedback, which is critical, but sometimes that feedback is at odds with what you're trying to accomplish.  Time-to-first-player was the distinguishing feature of the app, and users wanted something that went against this key feature.  As the designer this was a big decision, and I had to be the one to make it.  Well in reality, I didn’t make the decision.  I compromised.

The first week of February, I started working on animations.  I couldn’t decide what the animation should be.  I imagined a few in my head. I wrote a few to see what they looked like. Still unable to decide, I opted for letting the user choose his animation.  The pleasant side effect of this is that I now have an animation that is no animation.   Most of the animations take a full second to move the start player indicator.  The None animation is essentially zero, just like before.  That’s a compromise.  And as long as I’ve got to have settings, I added one so user’s can turn off the “auto re-randomization”.   

By mid-February I was ready to beta-test again, I had a new plan (2 weeks of beta-testing and then release!).   As I started my second beta I realized I had another problem.  Remember von Moltke?  IOS devices come in two aspect ratios.  The original iPhone and all the iPads are 3:2 ratio.  When the iPhone 5 came out, it was 16:9. I realized all my development and testing had been done on iPhone 5.  When I looked at the app on an older iPhone, or an iPad, you could see all of the tables for 6 and 7 players.  The solution was simple— re-write all the layout code.  So I did.  It took less than a week, but it was a big enough change I’d need plan #3.  These changes were a bit more radical, so I added another week to beta testing, and I could release in mid-March if things went smoothly.

Remember von Moltke? This time the problem was a truly odd one.  One of my testers reported a bug with the None animation.  The First Player indicator simply did not show up. I tried it and it worked fine.  Very little is more frustrating for a programmer than to know there is a bug and not be able to reproduce it.  If it had been one of the other animations, I could have just removed it, but this was about time-to-first-player.  We theorized that it had to be with his phone being a an iPhone 5S and mine being an iPhone 5.  Unfortunately, there was only one iPhone 5S among my beta testers.   Plan #3 was dead, and didn’t know what I was going to do solve this problem.

I spent 3 weeks working on some ideas.  I even tried to get together with the iPhone 5S owner and tried to debug it while the phone directly connected to the computer.  But the complexity of the Apple development eco-system got in the way an this was not successful.  That’s when another gaming friend got a new iPhone 5S.  I quickly got him involved in the beta-test, and sure enough, the problem showed up on his phone too.  I started building custom builds with additional logging so that I could try to diagnose the behavior.  Two days and 4 beta-builds later, the problem was “fixed”.  It was really more of a work around for what I think is a bug in IOS, but they important part is the app worked.

One week later I submitted Fast First to the iTunes App Store.  It took a couple of days and one round of back-and-forth with Apple, but it was approved, and now you too can get a copy of the Fast First.