For the most part, and I don’t mean to be overly critical, there are better ways to pass your time than with most tvOS App Store offerings. This weekend, I decided to put together a small game. More specifically, I wanted to create a game that highlighted a few key design points.
When it comes to tvOS, you must accept a few basic realities:
- Users sit relatively far away from the TV. It’s vital that you test your app from across the room and not just at your computer.
- Users cannot touch the TV. Well they can but it isn’t part of your app interaction and it gets the TV dirty.
- Users will at a minimum have a remote control on hand, probably a Siri remote. All apps must be written with that as a common denominator. Given Apple’s controller policies, I don’t really see hardcore gaming taking over the Apple TV platform any time soon. I made sure that my game worked with the old style Apple remote as well as the Siri remote.
- Users may get up and go grab a soda or hit the bathroom at any time. It’s nice when the game waits for them to come back.
- There may be several people in the room at the same time. An app shouldn’t be single-user centric. I see far more opportunities for integrating the platform into family and social situations, even for single-remote apps.
It’s these social situations in particular that got me thinking about living room play, and how some lessons of Wii Party/Mario party might transfer to tvOS. With multiple people present, you’re never going to fully immerse yourself in a game, but that’s not really a bad thing. I love apps that bring people together and enable them to interact both with the app as well as each other.
I decided that I wanted to write a slow game. I first heard about “writing slow” when doing background research for a write-up about A Dark Room. Although I don’t think tvOS is well suited for the kind of play-by-waiting game that A Dark Room represents, the notion of programming around time and its passage really grabbed me.
So I started thinking about what it took to slow down my trivia game to make it more suitable for playing in the living room with other people around, allowing time for talk and debate. I added a lot of “wait fluff”. To pick a category, you spin a wheel.
Each question is delivered into place by a helper. Questions don’t just pop onto the screen:
Questions slowly fade into view and when you answer, the answers fade to reveal your results. After that, the continue button takes a second or two to appear, letting you absorb before moving on.
Designing for Discussion
As a big motivation, I didn’t want this to be a single player game. When testing it with my kiddos, I observed their “skinner box” impulses of “answer/reward/answer/reward” and designed against it.
As I introduced each pacing change, the game itself changed for us. It was still a bunch of trivia questions but now we started talking about the possible answers, which ones we thought were right, and weighing our choices because we were no longer under any pressure.
I also opted to eliminate all scoring and “rounds”. Nothing ties you into to this app. You can hop in, play some questions, and hop right back out. It’s stateless: much more like a deck of trivia cards like the ones you might carry along for a car trip than most of the other offerings on the app store.
That casual in-and-out makes it a lot easier with social situations. “Wanna play a few rounds of trivia” creates a much lower entry point than “Let’s play a fully structured game”. In this, the game serves the people playing it, and not the other way around.
Unlike touch-based apps, I wanted Triviata input to be as simple as possible. I was in a mindset of “be the remote, respect the remote, limit the remote.” In fact, I reduced the entire interaction language to clicks. There’s a lot of clicking in this app.
Of the six buttons in my app, two of them are automatically selected for you. They never feel like “real” buttons, such as the “Click to Play” on this screenshot, which uses a custom button style to avoid highlighting.
The other four buttons (the answer buttons) use strict up-and-down selection. I could have built much more complex gestures but I needed interaction to be brainless and intuitive. I wanted to deliver lightweight access to the questions and answers.
I ended up chopping out a lot of code that didn’t make the final cut. I’ve got some nice work done on other interaction styles that I may end up using elsewhere (for example, rotating the controller to pick from a dial — this can also be used to “drive” the remote when held sideways as a steering wheel). I’m not at all upset that I ditched everything. I think there’s a lot to be said for simple.
I also went simple, simple, simple with each screen. Lots of whitespace, few on-screen elements. As a point of comparison, consider this screenshot from a competing app. This is a ready-for-gameplay presentation.
Imagine trying to read that from a normal couch distance. I’ll give credit for their Jeopardy set-up for structured gameplay but even this felt way too busy:
I like the design on this one a lot more but again, think about those small text features when placed across a room:
This next app opted out of multiple choice. You have to “think” or shout your answer before it’s revealed. That’s actually an intriguing way to involve group dynamics…
Of the apps that aren’t actually my app, this is probably my favorite presentation. They went with timed questions. I went more zen. I do however like the clean setup and the gray “whitespace”.
In the end, I expect to sell all of about 6 or 7 copies of my app. (Thanks for the coffee money!) It really was more an exploration of design and interaction principles than full-blooded app development, even if I think the end-product is fun to play.
If enough people buy the app, though, I promise to use some of the money to buy better trivia packs. I used public domain ones and some of these questions date back to the neolithic periods and not in a good way.
Got feedback about my app in particular or tvOS design in general? Let me know.