Fast First, a Designer's Diary, Part 2


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.

Fast First, a Designer's Diary, Part I

This is the first of multi-part article describing the design and development of Fast First.

The Idea


The idea for Fast First came about in July 2013.  I'd been using an app with a spinner.  Changing the number of players was always a bit twitchy.  One friend, Leon, used an app where every player puts a finger on the screen, and then it lights up under one of the fingers after flashing around for a bit.  I was generally unhappy with the options.  Then a friend mentioned another app that was available on Android.  As he described it, when started, you were presented with 12 button keypad with numbers on it.  When you press a button, it tells you how many players around the table is the "go first" player. I found this intriguing. That's what started the ideas bubbling in my head.

I was busy wrapping up work on scOra et Labora, actively working on Score La Boca, and adapting to the challenges that IOS 7 was throwing at me.  And of course, working on some board game designs.

It didn't take me long before I decide the concept could be improved on - why even spend the time to pick the number of players.  Let's just answer the question for all of the inputs in parallel. In less geeky terms, answer the question for a 2-player table, a 3-player table, a 4-player table, etc. all at the same time.  To do that, I knew I needed a good visual representation and I came up with the idea of a schematic representation of players sitting around the table. All I had to do now was build it.


In mid-October I started coding the app.  From the very beginning, the focus was on speed.  I’m not talking about optimizing code structure in order to shave microseconds.  The measurement that mattered to me was from the time I loaded the app, how long until I had a first player. This concept, which I've begun to call time-to-first-player, would be the distinguishing characteristic for the app. I tried to keep that as a focus as I banged away at the keyboard.  Four days later I had something with minimal functionality.  

Early visual for Fast First.  (I did say it was ugly)

Early visual for Fast First.  (I did say it was ugly)

With  time-to-first-player as a focus, I needed to remove the human from the process as much as possible.  When the app starts, when the screen is unlocked, or if you switch away from the app and then return,  I made the app re-randomize the tables.  Knowing when the user needs a new start player is one of the keys to the speed.  So I added that and eight days after I started I was ready for alpha testing.

One of my goals in alpha testing was to get visual design ideas.  I’m not a great visual designer and I freely admit that.  I had something that would work but it was very ugly.  Still, I started using it when playing games, and I showed it off to a few people to get feedback. I knew it was ugly, so I sought design advice from another friend.

Final color scheme and layout.

Final color scheme and layout.

About a month later, I implemented a revised visual design. The new color scheme was a small change, but it had a big effect. Making the gap between tables the same color as the tables made the whole thing look so much better.  The app spent another month with just me using it.

I was ready to expand my audience, but things were a little too cryptic, and I wanted just a bit more functionality.  In late December I added four small features that I think helped make it complete:

  • The drill-down to see complete player order (like you need for a game like Power Grid),
  • The legend at the top.
  • The verbal description of who’s first (partially added to deal with skeptics who might be sitting at the table).
  • The tutorial.  I love the way the app works, but I recognize that for a first-time buyer, it might not be clear.


With these four features added, the app went into beta-testing on Jan 6th.  I had some friends agree to beta testing it and give me feedback.   My plan was to spend a month in beta-testing, and then release it.  3 weeks into the beta test, I felt good.  There’d been no bugs reported.  I hadn’t gotten a lot of feedback, but Atlanta Game Fest (a four day board gaming convention)  coming up was and I knew several of  my beta-testers would be there.

(to be continued...)

Score La Boca makes it to iTunes


Score La Boca is now available for download from the iTunes App Store.  Huzzah!  It's been quite a journey to get here.

  I first got La Boca (the physical game in late-June).  I immediately had the desire to write an app, and so it began.  I actually had a usable tool in about 3 weeks.  I added features and tested and tweaked and made new graphics and change things around. August, September and October have been about letting it bake. Special thanks to my Beta testers for helping in the baking.  Finally, in late October I submitted it to the app store, and two days later I found two serious problems.  What timing.  Fix those problems, and submit again, and now it's ready for you.

Download it, enjoy it, and give me feedback on the forums.