Don't miss
  • 1,973
  • 5,500
  • 5,703
  • 114

Designing for Mobile, for Browser, For Console – Understanding the Use case

By on July 4, 2012

Are you designing a game in Unity, or HTML 5? Have you decided to lead development in the browser, because then your game will be be playable in any device that can read a web page, whether it be a PC, a smartphone or an intelligent toaster? Do you think of "platforms" in terms of technology?

STOP! You are making a terrible mistake.

The fundamental difference between the different platforms that gamers are using these days are not mainly about technology. They are mainly about input methods and use case.

How will your user interact?

The difference between a smartphone game and a browser game is not predominantly about technology. It is about the difference between a touch interface and a mouse/keyboard combination.

So if you hear your CTO saying "we’ll make the game in HTML 5 or Unity so we can launch to whichever platform we need", remember to ask "and how are we going to make the game work with a touch screen?"

The user experience is a much tougher problem to solve than the technology issue.

Where will they play the game?

When I was a child, I used to play on a ZX Spectrum. If I wanted to play a game, I had to get my Spectrum out of a box. I had to plug two leads from a cassette player into the computer. I had to press play and wait while the computer loaded in a program by decoding the sounds played by that tape player. I had to play that game and if I wanted to play a different game, I had to go through the whole rigmarole again.

I expected my games to give me quite a lot of enjoyment in a single session.

There is a strong correlation between how much effort a player has to go to to start playing a game and how much enjoyment he or she expects from that play session.

For most of us, our mobile phone is never more than 5 feet away from us at any point during the day or night. If we decided to play a game, it is probably only a few seconds between deciding to play and being in the thick of a game.

At the other end of the spectrum, a console game is a real commitment. You have to walk into your living room. Turn on your big screen and wait for the PlayStation 3 to boot up. You might be forced to do a mandatory update. You navigate across the screen to find the game in amongst the television options, the browser and the other media options. You have to wait while the game checks to see if it is up-to-date and forces you to patch. You wait while the game loads, pulls in previous saves, hits you with a few warnings and, eventually, lets you play.

You better have a good, lengthy experience if you are going to get through all of that.

This is how I think of "use case":

  • Mobile: 5 seconds from deciding to play to playing. Very short interactions (e.g. restock one floor in Tiny Tower) are satisfying.
  • Tablet: 20 seconds from deciding to play to playing (getting your iPad out of a bag, or settling down on the sofa with it). Short interactions (restock your entire tower).
  • Browser: Longer than a tablet, maybe one minute? A browser game can be fired up very quickly if you are already sitting at your desk, avoiding work. It is entirely possible to have a very short play session (Alt-Tabbing to a Facebook game to collect rent or harvest crops, for example), but it seems to me that players are likely to be looking for a more significant interaction than they are with, for example, smartphones.
  • Console: At least 5 minutes from deciding to play to actually settling down in front of the thing that you want to be playing.

Making the player happy

Note that these timings are not about how long each play session should be. You can have an equally long play session on each platform. It is about how you motivate the player to return to your game.

A mobile player will happily snack for a 30 second experience while waiting for a TV show to start, but if you design an immersive experience, he might stay playing for an hour.

A console player would be unlikely to boot up a PlayStation just to harvest a few crops. She would be more likely to return to a game because of a promise of an extended, immersive experience lasting an hour or more.

When you are thinking about the consequences of designing for a tablet instead of a console, for a smartphone instead of a browser, stop thinking about the technical implications.

Think about the user implications. You will be much more likely to design a successful, popular game if you do.

About Nicholas Lovell

Nicholas is the founder of Gamesbrief, a blog dedicated to the business of games. It aims to be informative, authoritative and above all helpful to developers grappling with business strategy. He is the author of a growing list of books about making money in the games industry and other digital media, including How to Publish a Game and Design Rules for Free-to-Play Games, and Penguin-published title The Curve: thecurveonline.com
  • http://twitter.com/Sikthehedgehog Sik

    Some silly analogy that just came to my mind: this is akin to cooking in an oven vs. cooking in a microwave. Sure, microwave heats faster and also keeps track of the time which may seem like obvious advantages, but thing is that it works in a completely different way and in the end there are a lot of recipes that can only be done in either microwave or oven, and not the other one (not to mention you can’t cook everything in a microwave, e.g. eggs will most likely explode).

    The same way you need different recipes for ovens and microwaves you also need different experiences for different gaming platforms. Most of the time they only work where they were intended and will need to change if used elsewhere (if that’s even feasible).

  • http://www.nicholaslovell.com Nicholas Lovell

    I think your analogy is apt. Or particularly, the way it makes it clear that different devices need different approaches.