(For more resources on iPhone, see here.)
Users have few expectations as to what a typical mobile application should feel like, there is often an expectation with regards to what a game should play like. Mobile gaming platforms have been popular since the Game Boy's rise to popularity in the early 90s, and users have an idea as to what games work well when on the go, and iOS games are expected to match or exceed these preconceived notions of what is possible.
However, it isn't necessarily easy to produce a game on iOS, as the device presents one of the first touch screen mobile gaming experiences. There isn't much precedent as to what game genres and control styles work well. This can be beneficial for innovation, but can also lead to a great deal of heartache for any designer.
Planning your game around touch
Unlike traditional mobile gaming platforms, we won't have physical buttons and a set interface blueprint to serve as a guide for our game.
Mobile platforms such as the Game Boy or PlayStation Portable have a physical control pad and buttons that lend the user to an inherent understanding of the game on screen. The user can quickly pick up and play a game, because they know that there is a finite set of buttons that can control game mechanics.
We're in a bit of a more difficult-to-manage scenario with iOS, as there is no control pad or face button to commonly dictate interaction on screen when in a game. Since we're on a touch screen device, we can create any interaction mechanic that we'd like, no matter how unorthodox the interface may be. This offers up an extraordinary opportunity for new gameplay experiences; however it does make our design work a bit more difficult to construct.
In this recipe, we'll discuss how touch screens drastically alter the design and playability of our game. Designing a game around touch is never an easy task. Controls are difficult to implement, screen size is often limited, and we'll need to innovate on top of standard game play mechanics to provide a fun experience.
While the operating system is only a few years old, there has been a significant evolution in gaming on the platform. Early games, such as Super Monkey Ball by Sega, were often ports of previous console games by big name publishers. Apple's affordable developer program allowed independent developers to step in and experiment on the platform, pushing forward intuitive new experiences like Doodle Jump, Mr. AahH!!, and Zen Bound. In recent years, the market has matured so that both traditional franchises and independent creative ventures can succeed.
To work on this recipe, it would be useful to have an iOS device along with a traditional gaming console in order to contrast the difference in mechanics between the two machines.
How to do it...
Depending on the type of game we plan on developing, there are a variety of strategies for success on the iPhone or iPad. However there are a few key attributes that will make any iOS game enjoyable:
- Remember that users will be using the iPhone or iPad as both a screen and a controller.
- Don't punish users for accidental interactions with the screen.
- Keep in mind that these are mobile devices.
While a good portion of our interface will vary greatly depending upon the type of game we're looking to create, these three rules are universal and will benefit any iPhone or iPad game. With these guidelines in mind, we can move on and begin to draft up our controls and heads up display.
How it works...
The low level of entry and unique touch controls have helped iOS evolve into a platform where designers can reach outside of their comfort zone in an effort to release an innovative game on the platform.
In step one, it's important to understand that traditionally, users and designers are trained toward expecting games to have an external controller that is used for manipulation of the game world. The screen is a separate device; either a television or portable LCD screen serves as a way to project the game.
However on iOS, the screen and controller are one. Regardless as to whether users interact with our game through buttons on screen or by using a device hardware feature such as the accelerometer, it is a guarantee that the iPhone or iPad will be held in a hand while our game is being played.
We should always keep this in mind when designing both our game and interface, as the user will need to comfortably hold the device while playing. If we use traditional controls through a software joystick or buttons, we should place these elements on screen in a manner that allows for the iPhone or iPad to be held comfortably while playing. Depending upon our game and orientation, we may find that specific parts of the play area are perfect for the placement of such controls while in other scenarios, we may want to give the user the ability to customize the placement of buttons to their preference. If we expect the user to tilt or shake the controller to interact with our game, we should take this into consideration as well.
While it may sound somewhat clichéd, the game and its controls are one and the same. There is no separation and any design that assumes that we can quickly implement controls without taking this fact into consideration is destined to fail.
Not being given a set control pad or buttons gives us the flexibility to be creative, but poor design can quickly confuse or frustrate users. In the next screenshot, we can see that Flight Control developer Firemint has used small exclamation point markers to offer up a hint as to where inbound aircraft will soon appear. This offers a quick heads up to the user who may have had their hands in a poor position.
Flight Control - © 2009 Firemint Pty Inc.
We expand upon this new type of game control with these new devices in step two in the previous section. Because the game controller and device screen are so intertwined, it's very likely that the user will come into accidental contact with the screen at some point. It's just too difficult to eliminate unintended taps, as the finger is an imprecise pointing device.
We can assume that the user will make unintentional contact with the screen, and so we should do our best to design a play mechanic and interface that will not punish users for their mistake. For example, if we're building a racing game, it would be silly to place the pause button near the button used for acceleration, as misplaced fingers could often pause the game and frustrate users.
How we go about verifying this in our application can vary based on the type of game we're looking to design, but we should be mindful to keep this philosophy salient in our work. The limited ability to include a help menu in our application will encourage users to pick up app controls through point and tap experimentation. If the user experiences frustration in their first few minutes of using the app, they'll be likely to give up on using our app.
Finally in step three, we should focus on creating an interface that is mobile. While we're designing with a device that is nearly as powerful as home gaming consoles, we must keep in mind that our users will be using their iPhone or iPad when on the run. They may be playing our game on a train, or in the car, or when walking between classes, so it's important to remember that this is a slightly different game platform than what we've ever developed for before.
Because users will be playing our app when on the go and users will be less likely to sit down and play our game for extended periods of time, we should prepare our gameplay and interface around this probability.
Big buttons and forgiving controls are the best way to go about designing for a mobile interface. Larger targets on screen will make it easier for the user to perform an intended action, even when walking or riding around.
If we'd like to take mobile usability a bit further, we could also implement modifiable controls into our app as well. Giving the user the ability to calibrate settings will enable our game to play well, regardless as to the situation they're currently in. In the next screenshot, we can see how Doodle Jump allows users to adjust the game's controls:
Doodle Jump - © 2011 Lima Sky, LLC
It's also important to note that we should design our interface for the rapid entry and exit that is common of iPhone users. People will be playing our game on buses, while waiting in line at a store, and in other scenarios where their time spent inside of the app may be no longer than one to two minutes. This will affect game play drastically, so it's important to test such game scenarios while we build our app.
Because our first iOS game may be our first touch screen based game, or our first game in general, we should be cautious and conservative with our interface and game play mechanics.
That's not to say that the creation of any game is easy; however these are significant pitfalls that could plague our work if we're not careful.
While rare, there is the possibility that our iPhone can be used as a controller for a device other than itself.
Using the iPhone as a controller…for the iPad
Thanks to the Bluetooth integration that Apple has included in new iPhone, iPod touch, and iPad devices, it is possible to use our iPhone as a controller for iPad games, so long as the developer has produced games for both platforms and supports the feature.
It isn't necessarily easy to design and develop a game that includes such a feature, but it is by no means impossible. If we're working on an expansive game, it is definitely possible to create an immersive experience where the iPhone is used to control action on the iPad.
(For more resources on iPhone, see here.)
Using control techniques that are optimized for touch
Video games have evolved over the past 30 years to include several distinguishable and expected traits, especially with regards to controls . A joystick or control pad , and two or more physical buttons has become the standard that has seen universal success on multiple game platforms. From the original NES to the Dreamcast or Game Boy Advance, gamers worldwide have grown accustomed to such a scheme.
But game design drastically changes with a touch screen, as we need to properly account for how the user will hold our device, and what sort of control options will be comfortable to the user.
The fun factor of our game will be completely dependant upon the control scheme we implement into our work, so this isn't an attribute that we should take lightly. Whether we use a software control stick , software buttons , or any other interface mechanic, we should take ease of use into consideration.
For this recipe, we'll dive into different gameplay mechanics that have been proven to be successful on iOS.
To experience different popular control types on the iPhone and iPad, it would be useful to purchase games such as FIFA 10 by EA Sports, Doodle Jump by Lima Sky, and Ocarina by Smule.
Both a new and old iOS device would also be useful for this exercise, so that we can experience the differences in capabilities over hardware revisions, to see how the gyroscope or retina display can alter game design.
How to do it...
Before we determine which control type is most appropriate for our game, we should first look at a few common techniques for inspiration. Here's a look at several of the options that are available for our game:
- A traditional style using a software simulated control stick and action buttons.
- Pulling, pushing, and tossing game play objects using the flick gesture.
- Precise control utilizing the accelerometer and gyroscope.
- Use of a unique hardware tool such as the microphone as a controller for unconventional gameplay.
In understanding the gameplay requirements for our app, we'll be better able to judge if the style of each is suitable for our work.
How it works...
The powerful processors in the iPhone, iPod touch, and iPad encourage developers to produce expansive, attractive game worlds that are equal in size and scope to traditional video games. This is great for consumers, as their new phone or MP3 player is also a first rate gaming device. However, it can create a good deal of heartache for designers.
Because such traditional gaming environments are possible, users will expect familiar controls, which is why software simulated control joysticks and action buttons are so popular in many iOS games. We can craft an experience not unlike that of a console video game, and users have rewarded those apps with strong sales in the App Store.
However, the lack of tactile feedback and requirement for accuracy can make such a development strategy difficult. Pair this with the intuitive hardware features of the iPhone, and many developers have gone the alternative route and created unique experiences that innovate greatly on the new platform. If original and enjoyable, these games have performed wonderfully in the store as well.
Using the simulated control stick and control button technique, we will place interface elements on screen to stand in for physical buttons. A control stick allows the user to move in any direction along an axis and buttons perform actions. We can't provide tactile feedback, but we can fake the experience enough to make it feel familiar to the user. Using this method, we can replicate any fashion of traditional controller that fits best with our game. Below, we can see how FIFA 10 uses a traditional control style:
FIFA 2010 by EA Sports - © 2009 Electronic Arts Inc.
Perhaps the best, and most successful example of the flick gesture gameplay mechanic is Angry Birds. In the game, players use a slingshot to flick tiny birds at pigs that are hiding behind a variety of barricades. The game has seen strong commercial success worldwide, mostly due to its unique controls that are only possible on a touch screen device such as the iPhone or iPad.
By requiring the users to pick up and drag birds on screen in order to determine the direction and velocity of the birds, we guarantee that the player's finger will be positioned in a place where important on screen visual cues are not obscured. Likewise, dragging a finger on screen gives a surprising amount of direct control to the user, which when coupled with a strong physics engine, provides an exceptional sense of control, as seen here:
Angry Birds - © 2011 Rovio Mobile
Doodle Jump by Lima Sky is an exceptional example of tilt controls that are powered by the accelerometer and gyroscope. As shown in the next screenshot, the user holds the iPhone or iPod touch in their hand, and then tilts left to right to help the Doodler find platforms and avoid monsters. The controls are intuitive and it feels as if the user is directly controlling a world that lives inside the iPhone, which creates an enjoyable game play mechanic.
Doodle Jump - © 2011 Lima Sky, LLC
Our games can also utilize other device hardware features as well. Ocarina by Smule is an original experience and digital music instrument, where the user blows into the phone to play the instrument, just like a real ocarina. This is another great example of using the unique device features of iOS to create an interesting and fun entertainment option.
Picking a control type and accompanying interface is never a simple decision, and our choices will ultimately determine the success of our app in the market. The applications in this recipe should help provide inspiration and put us on the right track for application interface success.
Users and peripheral designers have been wishing for an actual controller attachment for iOS since the App Store's creation, but have they found success?
Using an actual control pad
Because the iPhone and iPod touch are such powerful devices with easily accessible API for app creation, consumers have demanded an accessory that gives the devices a physical control pad for several years.
It seems as If the development of a controller shell would be easy, but such hardware attachments would need Apple's blessing in order to interact with the standard 30 pin port used on all iPhone, iPod, and iPad devices.
Thus far, Apple has never approved such an accessory, and they don't seem interested in changing their minds here in the near future. Several homebrew, small-run test controllers have been produced which would work either through Bluetooth or through jailbreaking a device, but none of these options have seen commercial success. For now, it appears as if a controller attachment will remain on iOS developer wish lists.
(For more resources on iPhone, see here.)
Designing HUDs with limited real estate
The Heads Up Display (HUD) is an integral aspect of any game, offering graphical overlay information on the user's score, the number of lives remaining, information on current user attributes or power ups, progress through a level, and more.
If we're designing a game, we're probably going to need a HUD. However, since our touch capacitive screen also contains our control mechanism, we need to be a bit creative with how we lay out our HUD.
In this recipe, we'll give examples of several applications that offer exceptional HUDs that we can use for inspiration in our games.
We don't really need any concrete hardware or software for this recipe, but we should have a good grasp of what overlay elements we'll require in our application before we begin.
We don't need to have their final shape or size set, but we should have an idea of what we'll need screen real estate for.
How to do it...
The HUD plays an important role in a game, offering up updated statistics, scoring, and important information about the user's progress in our game. As such, the HUD should flow well so that the user can quickly find this information when necessary without causing frustration. On the iPad and iPhone, this is a bit more difficult than a traditional gaming console, as we may also have game control buttons placed upon the screen as well. Here are a few tips for HUD creation:
- In designing our HUD, the first thing we should determine is what important elements are required for the user to successfully play the game.
- If we find ourselves adding seemingly too much to our HUD, we should keep in mind that it is possible to keep less essential game information on a pause screen if need be.
- Arguably the most important attribute to keep in mind when developing a HUD, is the assurance that control elements are clearly separable from non-interactive HUD content, and that our HUD never be covered by our hands while playing the game.
While we design our HUD, we will see success so long as we keep in mind the fact that the user will need to interact with the screen to play the game as well. So long as it's clear as to what on screen elements are interactive, and we place other informative on screen items in a location where it will be consistently visible and unobtrusive, users will find great utility in our HUD.
How it works...
When people think of the most important attributes of a game, they often first have controls or graphics come to mind. The HUD is often never even considered as an important attribute, even though it may be the most significant aspect of the entire design.
In reality, people don't cite the HUD as important because it's the unappreciated aspect of the system that no one really ever sees. If the HUD is good, it blends in so well and is nearly invisible so that the user can always focus on the game at hand and is never distracted by it. If the HUD is bad, users will focus their frustration on the game in general, overlooking HUD design flaws and assuming that the game itself is bad.
For the first point, we'll want to provide a HUD that offers up all the information that the user will need, while not crowding the play area. On iPhone and iPod touch devices, we're already working with a small screen area as it is, and we shouldn't over clutter our interface.
Shown in the next screenshot, The Incident succeeds with a minimal HUD, where important elements somewhat outline the screen. This helps to guarantee that the user can always keep attention on the game's fast paced action.
The Incident - © 2011 Big Bucket Software
With regards to the second point, we should consider moving cluttered on screen items off to a pause menu if need be. Through the pause screen or deep menu items, we can keep our game screen orderly, while offering relatively easy access to such game options. Game Dev Story is one such game that works well with a deep menu system.
Game Dev Story - © 2011 Kairosoft Co.,LTD
Hand placement should be the primary focus with the third point. We should make sure that buttons are clearly buttons so that users can properly hold and manage the device during gameplay. When designing an artistic vision for our buttons and background items, we should be sure to make our interface elements distinguishable and clear to the user. Seen in the next screenshot, Chu Chu Rocket implements a clean HUD with clearly labeled interface buttons, making the game easy to pick up and understand:
Chu Chu Rocket - © 2010 SEGA
On the surface, this makes the HUD seem like a somewhat thankless addition to our work, with no user noticing enough to appreciate the work. However, once we begin to understand the subtle traits of good HUD and their impact on a game's success, we'll realize that the entire experience is dependent on good work. By working to optimize our HUD as best we can, we'll be making the right steps toward designing a successful game.
While developing our HUD, we may find it difficult to limit the amount of information we need on screen. We may also find it difficult to best present such options on screen. What do we do in these situations?
If we find ourselves having difficulty, we should remember that iOS is a completely flexible design canvas. If we're unsure of what is best, we can always integrate a settings page into our application where users can make a decision on what best works for them.
This flexibility can give users a variety of options, allowing alternate interfaces for left handed users or even the ability to drag and selectively place elements if we want to work such a feature into our app.
There is no requirement that we offer such customization, however it can be a simple way to increase user satisfaction for our game.
Accounting for the lost Status Bar
Because a game is typically full screen, in order to provide an immersive experience in our game, we'll lose the important 20 pixel Status Bar located on the top of our iPhone or iPad screen.
The Status Bar contains important user information on connectivity signal, the time, and battery life; we may not want to completely remove this functionality if we can avoid it. Users often enjoy such features and may want to know how much battery life they have or what time it is when playing our game. However, we don't want them to close our app in order to find this information.
In this recipe, we'll discuss ways in which we can best go about keeping these features inside of our application, so the user is never forced to leave midway through a game level.
Either the iPhone or iPad will work well in this recipe, as both will give an idea as to the significance of losing the status bar.
It also may be useful to read up on the iOS Date and Time programming guide , located at https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/DatesAndTimes/DatesAndTimes.html.
You may also find interest in the Battery Status sample code project , located at https://developer.apple.com/library/ios/#samplecode/BatteryStatus/Introduction/Intro.html.
How to do it...
The Status Bar is an integral aspect of iOS, offering up essential information on every device. iPhone and 3G iPad devices place important signal strength information in the upper status bar, and all devices show the current time and battery level in the top bar as well.
This data is key for the user, especially information like battery life, as the user may be unwilling to continue using their iPhone to play games if the battery level is low and they need the phone to be usable and are unable to charge the device immediately.
However, problems arise as we design a full screen and immersive game application. Either we'll need every available pixel for our game, or the Status Bar will appear out of place, and we'll need to remove it from our work. But once we remove it, it will become quite clear to the user that they're unable to access this important information.
Luckily for us, Apple has offered wonderfully simple API to tie into, which will help us include the time and battery information into our game. The only problem that we must seriously deal with is the question of where we place this information.
The simple placement position is on a pause menu, however it's astonishing as to how many games and full screen applications either forget or refuse to attempt to include such data, even though it's extremely easy to implement. Two different possible inclusions of this data are:
- Integration of time and battery information into a pause menu so that the time and battery information fits into our game's art style
- Inclusion of the standard status bar into our game's pause menu
It's a minor addition, but will increase the likelihood that a user remains inside our application and creates a better experience for everyone. It's a win-win situation that helps to create an app that will ultimately receive better reviews on the App Store.
How it works...
The Status Bar is an iOS fixture, and the interface element that is most prevalent throughout the operating system, appearing in all but a handful of situations. It's also the least customizable interface element, as we're only able to alter a few aspects of its color.
With the bar also containing important data on device power and cell signal, users are going to need this data at some point. It's best to make sure that the user has a way to always access the information.
For the first suggested method of inclusion, we can easily create a stylized clock and battery icon to provide such information to the user:
The Incident - © 2011 Big Bucket Software
The Incident is an application that provides exceptional inclusion of time and battery data. In the previous screenshot, we can see a clock and battery indicator in the same enjoyable pixel art style that is found throughout the game. This method of inclusion is a wonderful way to retain the fun, playful styling of the game while also offering a feature that is extremely useful to the user.
If we'd rather go with the second suggestion and provide a more traditional display of information to our users, there is also nothing stopping us from throwing the standard Status Bar back into our application when action is paused as well. Zen Bound 2 goes about replacing the Status Bar when paused, and as shown in the next screenshot, this works quite well for the user by providing a recognizable and clean presentation. This also allows for us to give the user access to the cellular signal, as we're unable to tap into signal strength using the approved API.
Zen Bound 2 Universal - © 2008 Secret Exit Ltd.
Regardless as to how we decide to include the Status Bar information, either through a playful and styled display as is seen in The Incident or through an implementation as seen in Zen Bound 2, this ability is extremely important to the user and we should work to include it in our interface.
Luckily, Apple has offered APIs such as the iOS Date and Time programming guide and Battery Status sample code project to help make programming this data into our application easy; we only need to go about designing ways to include it into our interface. This isn't an easy task necessarily, but with a bit of work, we can find a way to replace the Status Bar within our game.
Once users aren't forced to leave our app to see how much battery life is remaining or for the time, they'll be more comfortable playing our game for an extended period of time. This will lead to greater enjoyment, and our application will be more loved and receive higher rankings in the store.
In this article, we dived into designing a game on the iPhone or iPad, along with tips for how we can ensure a quality experience for all users on these touch screen devices. We discussed control techniques optimized for touch, heads up displays, and a variety of techniques to best make our game enjoyable on the iPhone or iPad.
- Development of iPhone Applications [Article]
- iPhone: Issues Related to Calls, SMS, and Contacts [Article]
- iPhone Applications Tune-Up: Design for Performance [Article]
- iPhone: Customizing our Icon, Navigation Bar, and Tab Bar [Article]
- iPhone User Interface: Starting, Stopping, and Multitasking Applications [Article]