On Designing a Game Timer

/

"Add a timer, how hard could that be?!" you say.  

Seems easy enough, but introducing one to the UI in a way that doesn't suck isn't trivial, nor are all the easy to miss corner cases that need addressing. Adding this simple feature is easy, getting it right needs some thought. Let's take a wander through the thought process behind designing the new timer that shows up in Mutility 1.3. 

Where Does It go?

I looked at all sorts of places to put this thing:

  • One in each player panel
    • Pros: Each player always has a timer oriented towards them for readability
    • Cons: Clutters the clean player panels. Up to four numbers ticking away all the time is distracting and sort of redundant.
  • In the main button bar, toggled on by a switch in Settings
    • Pros: It's a secondary feature, so would be hidden until the user decides to turn it on, keeping the clutter down for everyone else (Doesn't take up any space on the main bar when not in use). Adds value to the in-app purchase by making it a paid part of the customizations. 
    • Cons: Trying to cram it into the main bar with the rest of the icons is a big mess. Putting it on a secondary button bar would be another step after the user has toggled the timer on. No way to do this simply and cleanly.
  • In a secondary button bar, toggled by a button in the main button bar
    • Pros: Giving the button prime real estate makes it simplest to use and can use the existing sliding bar mechanics to toggle it back and forth. 
    • Cons: An icon from the main bar has to be removed to make room for the timer toggle button, making that feature less obvious to the user.

I looked at all of these options, partially implementing and testing each way. The best implementation turns out to be the third way, even though it requires banishing a button from the main bar - the dice roll button. No other button could be moved, since they either bring up modal views or slide in a bar. The dice roll button has been moved to the game bar (the one you get when tapping the new game button), which makes sense since a dice roll typically happens at the beginning of a game. UI figured out, BOOM, moving on to the hard stuff....

What are the gotchas?

When figuring out how to implement a game timer, you come up with all sorts of questions (and hopefully answers). Here's my internal Q&A session:

  • Should it start automatically when a game is reset? 
    • No. When resetting the game, you may not immediately start again, or even want a timer. Firing up the timer should always be done manually to avoid unwanted behavior. 
  • What dedicated controls does it need?
    • Pause and reset. You need a dedicated timer reset so the whole game doesn't have to be reset simultaneously. Resetting the timer and resetting the game are not always coupled.
  • What happens when you switch games? (2 player to 4 player, for example)
    • Pause the timer. Switching to another game probably means that the user isn't involved in the previous one any more, so it doesn't make sense to keep the timer running.
  • What happens when you switch to another app?
    • Keep the timer running. Remember, we're running on a smartphone. Over the course of game you can expect the average user to leave the app to deal with messages, answer phone calls, send x-rated Snapchats, etc. If they had to un-pause the timer every time they came back into the app, it would be a huge pain in the ass and they'd stop using the feature.
  • What happens when the timer is running, the user switches to another app, and iOS kills Mutility to free up memory?
    • iOS is very aggressive about closing backgrounded apps when there's memory pressure. The way the timer is implemented must be robust enough to handle the app being killed. When the user re-opens the app, they don't know that it's been killed, and nor should they. It's on me to make it look like it was running the whole time.
    • When the app enters a backgrounded state (i.e. you switched apps), I stop the timer and record the time I did so. When the app enters the foreground again (i.e. you switched back to it, or it was killed and was reopened), it looks to see if the timer was supposed to be on then computes what the elapsed time should have been. By just assuming it's going to be killed, all the guess work is removed, and it appears to the user that the timer has been going the whole time.

How can you make it more fun and intuitive?

I spent a real lot of time working on the icons for this feature and went through various incarnations of what a stopwatch icon should look like. The icons should be instantly recognizable as being related to a timer, fit with the style of the existing icon set, and include little details that can help give context to what's going on. I'm very happy with how delightful the little details worked out to be:

  • When the timer is running, the stopwatch hand on the main button bar animates ticks in sync with the elapsed time. The animation is subtle, but you can tell at a glance if the timer is running even if the timer bar isn't visible.
  • The position of the stopwatch icon's start/stop button is down when running, up when stopped.

So that's it. I'm nearly done with 1.3 that includes this feature - should hit App Review in the next couple days and be in the store sometime next week.