Shh! iPhone gaming should respect your sound settings

This one may be hard to illustrate, but it should be one of the first items on the checklist for developers, and is often missed. Let’s use a scenario to illustrate it, painting vivid pictures in your mind!

---

You’re sat in a lecture, and the topic is domestic life in 14^th Century Catalonia (We don’t know why you’re here, you are a computing student. Maybe you thought there would be sandwiches). It’s dull. You’ve tried to check twitter, no internet connection. Time to play a game on the iPhone then, I guess. Check the phones on silent, yep the switch is flicked. Ok, time to rock!

Oh no – its playing the Marble Zone theme at full volume! We’ve been foiled, and you’ll never get the sandwiches now!

---

So what went wrong? Despite having the phone set to silent, the game still had sound. Depending on how diligent the coders were, this has been an issue with the iPhone for a while, as the iPhone won’t automatically silence apps when set to silent – this has to be manually coded. Quick ports or just forgetful coders (usually working in small teams) can miss this.

This becomes an issue because of user expectations – they’d expect the silent switch to work globally, and will be surprised and frustrated when this isn’t the case. As seen in the scenario above, it can lead to the user being embarrassed and worse of all (according to Alan Cooper) feeling stupid!

It’s not simply a ‘design choice’, as a logical look at the situation will tell us. Not only would manually setting the desired volume settings inside an application duplicate functionality that is already implemented in a much more functional manner on the device itself, but I can also think of no scenario where a user would want their phone on silent, but their game to make sounds. It’s just poor design.

So in summary… just don’t do it app designers!

(Also while you’re at it, let me listen to my own music in game!)

Who does this well?

 A lot of games to be honest, as its not really a ‘do well’ thing, rather its just done or not done. So lets talk about Doom Classic, as it does do this. John Carmack’s finally (6 months after it was “almost ready”) released his port of the original Doom for the iPhone. Control issues aside, it’s a faithful port, and includes WiFi multiplayer. Its Doom, so you know what you’re getting, and its just as fun as it was 15 years ago. More relevant, it does respect the silent switch on your iPhone, so I’m justified in talking about it here! We’re all looking forward to when Carmack starts on his port of Quake.

Who does this badly?

Hook Champ, from Rocket Cat Games, is a fun platformer where the only means of getting anywhere fast involves swinging from the ceiling, over lava, through brick walls and away from the scary cursed..fish thing. Its fun, recreating the opening scene from Raiders of the Lost Ark. It’s just a pity that the game ignores your silent switch, and so plays at full volume regardless of your iPhone’s settings. You can set the volume in game. But you shouldn’t have too. A disappointing oversight!

Another offender is Sonic 1, but I didn’t feature that as I’ve already talked about it in a previous post (link to previous post). Oh dear!

 

Also, just quickly, thanks to Brian Franklin from WebHostingSearch for featuring this blog in their ’20 Great UX blogs’. Rather unexpected, but thanks!

Controls should be appropriate to the iPhone’s input methods (shake now!)

Part of a series on iPhone Game Design Issues. For an introduction see here, or use the categories on the right.

Looking at an iPhone, the immediate thing that strikes most users – compared to other mobile devices – is the lack of buttons. There are 4 in total, and all have very set roles – the power button, the silent switch, the volume control, and the ‘home button’. The home button is the most prominent of these, and sits on the front of the device, below the screen.

All of these buttons are useless for gaming – three have very specific roles, and the home button is exclusively used in the iPhone OS to exit programs and return the user to their ‘home screen’. What this means for gaming is that the device is lacking a critical element that users of consoles have come to rely on – tactile feedback when pressing a button.

 

Buttons on controllers are important for many reasons.

The physical shape and size of buttons are ideally ergonomically placed to make the controller comfortable, and prevent gaming being a painful experience. They should also be placed in places that become intuitive to the user – gamers, like touch typers, should be able to forget about the controller’s physical presence between them and the game, and react naturally to events on the screen without having to think about how to translate their actions through a control pad.

 

And then theres the iPhone. Game developers aren’t allowed access to any physical buttons for players of their game. They have to innovate (uh-oh!).  Or not.  Some developers, whether its due to the style of game they are trying to present, or just laziness, have just plastered on a ‘on screen joypad’ ontop of their game, with virtual buttons. See, for example, the iPhone port of Duke Nukem 3D.

 

So that’s 5 virtual buttons, and 4 virtual… test tubes?.. acting as directional controls (two for movement direction, and two for aiming). Obviously the medium of the game (a First Person Shooter), does need a large degree of complex manoeuvres to be performed, but it seems both lazy and ineffective to have these as virtual buttons. Not only does it take up a very large proportion of the small screen’s real estate, but without the physical presence of the buttons, it seems very likely that the wrong buttons will be pressed constantly. This causes the constant need for the player to think about the controls, and will prevent playing from ever becoming truly intuitive. The iPhone does contain tilt sensors, as used in other games as the primary control method, and this could well have been incorporated into the aiming or walking mechanics (although not if you don’t want to draw stares on the bus).

 

Instead of lazily placing endless virtual directional pads and buttons, developers should be taking the medium into consideration when implementing controls. The iPhone has capability for tilt sensor input, and multi touch (so multiple elements can be selected at once). This has been used successfully to produce games of most formats – in particular Rolando, a tilt platformer, and Doom Resurrection, a tilt FPS being examples of successful implementation of formats traditionally considered to rely on control pads. Moving from a control pad to the iPhone requires novelty and implementing new methods of controlling the games, rather than a simple port. Buttons just don’t work as well without tactile feedback, and totally disregard the other control methods the iPhone allows. As before, I’ll end with an in focus look at two games available on the iPhone, both platformers, one of which successfully implements a suitable control method, one of which fails.

 

Who does it right?

Rolando, by Handcircus, has been described as the ‘Mario of the iPhone’ (by someone). At heart it’s a traditional platformer, with goals such as getting to the end of the level while overcoming traps, obstacles and enemies. All standard stuff for the genre. However what it does correct is the implementation of this, taking into consideration that it is on the iPhone. To move left or right, the phone is tilted, removing the need for directional controls. A swipe on the screen will cause your character to jump – again no button here. Elements on the screen, such as the lift in the picture, can be manipulated with your finger, which of course your hand is free to do, as you are not restricted by using them to move. So, with Rolando, moving is intuitive, jumping can be done anywhere on the screen, and there is no need for virtual buttons and the problems we’ve identified surrounding them.  

 

 
Who does it wrong?

Sorry, but its Sonic. Obviously it’s a classic platformer, and an exact port of the version on the master system (so no spin dash!). However the port itself seems lazy – controls being implemented by simply placing a virtual d-pad and jump button on the screen. For a game that involves precision jumping, such as Sonic, this is a huge mistake. Lacking tactile feedback on which direction you are pressing, or whether you have your finger above the jump button, can (and often does) lead to missing jumps, and frustrating deaths. And, with no level-select, three deaths will mean starting the game from the beginning. Ultimately it makes the gaming experience frustrating and removes a lot of the fun that the sonic series used to be about! A design failure.

 

I think app store reviewer Mr Intesity puts it best:
 

Score: 2/5

Subject: I am cooking chicken and rice

Review: It’s alright. Its Sonic as you would expect but with dodgy controls. I’ve played it twice, too fiddly to sit and enjoy I found.

iPhone games should not be interrupted by calls.

Part of a series on iPhone Game Design Issues. For an introduction see here, or use the categories on the right.

The most obvious thing that can be said about iPhone gaming, and yet a factor developers commonly miss,  is that it appears on a phone. There are many ramifications from this, such as where a player is likely to be playing (the bathroom?). The focus today though is on the important factor that a phone is likely to receive calls.

 

Text messages are handled by the iPhone OS, and appear as a pop up box that can be dismissed, with minimal interruption of the game (and hence needs no input from a developer). However receiving a call will shut down the game and run the phone program regardless whether the call is answered. This is where good design is required to avoid a usability disaster.

 From a technical perspective receiving a call is essentially the same exit process as if the ‘home’ button (the only button on the main page) is pressed. However from a usability perspective, the important difference is that the user has no control over whether they receive calls or not, and so the software has to accommodate this. If the app just ‘drops’ you, without saving the state of play, and then starts the app from fresh when the call is finished/rejected, this is going to negatively effect the user’s experience. They will be unlikely to want to play again, since they will be redoing aspects of the game they thought had been completed earlier. Furthermore the fear that they will receive more calls, and thus lose progress, is going to be a lasting factor, and prevent the user from investing time to continue.

 It is therefore important for iPhone game designers to consider that the medium is going to lead to unexpected interruptions to game play, and provide a solution which will accommodate this.

Who does this right?

Scoops, the casual ice cream tower building game, successfully implemented this in a later version of their game.

In the initial release a call (or ending the game) would cause the game to restart from the beginning (without saving the high score). Despite being a short game (a typical session would probably be under ten minutes), the game’s only measure of progress is a high score table, and so losing progress like this can easily anger players. This was recognised, and fixed in later versions so that now the game will resume from where it left off after returning from a call. Further to this, the game will start paused so that players returning from a phone call can adequately prepare to resume their gaming session. The designer, Ian Marsh, has ensured that interruptions to game play will not hinder player’s progress in the game.

 

Who does this wrong?

Alive4ever, the zombie survival game ‘inspired’ by Left4Dead, has recently added a ‘horde’ mode, where users must survive waves of enemies of increasing difficulty in order to unlock additional bonuses.

Unlike Alive4ever’s other modes, where games would be in <5 minute intervals, successfully unlocking all the weapons in the new mode would require playing for over an hour without interruption. If the user intentionally exits the game, or receives a call, their progress in this mode is lost, and the user has to start the hour long session from the beginning. The implications of this are that the user will be unlikely to retry this, and the real enemy becomes not the zombies on screen, but the challenge of not receiving calls for an hour!

 

As a little bonus to finish on, here is a gem of an app review, for Scoops.

User: FredsYourUncle 
Score: 1/5
Subject: Fool
Review:  “ Tomatos arnt vegetables “