First, Graeme described what is different about the iPad. For all iOS devices, the joystick and physical buttons of classic game consoles are gone. An iPad-specific difference, however, is that the positions of the player's hands are quite different on the iPad versus the iPhone or iPod Touch. For example, when holding an iPhone, players generally cradle the phone in both hands, thumbs or fingers from both hands to interact with the device. With the iPad, generally one hand is supports the device from behind, while the other plays the game. He exhorted developers to consider all the ways users will want to hold the device while playing their game, and to factor that into their design choices. He also cautioned developers to play the game in the "wild," not just leaving their iPad flat on the desk, plugged into their Mac while developing, in order to experience these different hand configurations themselves.
Graeme considered the challenges of porting from PC to iPad, saying that there are no easy answers, and frequently many bad choices are made by games during this process. He gives the example of the iWork apps on iPad -- these are completely different than the equivalent apps on a Mac, suggesting that simply replacing the mouse cursor with the user's finger is not adequate. On a PC, you move your mouse, then select an item onscreen, said Graeme; with an iPad, the finger only touches the glass when a selection action is occurring. This is the most "key" difference between a desktop and an iPad, according to Graeme. He used an example of porting a puzzle from his game Clandestiny to iPad, contrasting a "simple" implementation with a carefully designed, iPad-conscious implementation in terms of usability.
Graeme thinks of touching the iPad's glass screen as if he is touching the world directly on the other side of the screen -- in other words, the player's fingers are interacting directly with the world. He cautioned developers not to put up artificial barriers between the user and the game world, such as virtual onscreen D-pads, which he unequivocally dislikes.
Some other aspects of designing for iPad that Graeme mentioned were making good use of the accelerometer to provide subtle 3D effects when the device tilts, and the importance of a high framerate. Although it may not seem important that an app such as Words with Friends runs at 60 Hz, he said, it becomes quite important when the user actually picks up a tile to move it around the screen. You can always throttle down the framerate when the player isn't touching the screen in order to save battery, he said.
After this, Graeme enumerated his list of best practices for iOS development, and development in general. These were as follows, paraphrased roughly:
- Do play tests with other people every day, and make sure to hold your tongue while watching others play your game. "You do not come with the game," he said, so the only way your game will improve is if you do not help the play test subject while he or she tries your game.
- Make your app playable on Day 2. With the short schedules common on iOS projects, the luxury of spending months on an engine before getting to gameplay is not available. As much play testing time as possible is necessary.
- The user should never have to manually save a game. The game should save automatically when they press the home button.
- App startup time is important. According to Graeme, over 3 seconds is too much. 10+ seconds risks people never playing your game again.
- Don't release as soon as your game can possibly be released -- spend at least 2 weeks polishing before you submit to iTunes Connect.
- "When in doubt, refer to the Zombieland rule set." Graeme suggests that the series of "rules" enumerated in the 2009 movie Zombieland come in handy in all situations.
- "What you are saying when you put a virtual D-pad is... my game is better with a joystick." The best games on the app store do not have virtual D-pads.
- Make sure your app gracefully supports being interrupted by notifications, home button presses, etc.
- If you are going to implement gestures in the game, be sure to give the player some sort of feedback as to what gesture the game "thinks" the player is doing well before they complete it. The player should get feedback as soon as their gesture starts, not have to wait until it completes and wonder why it wasn't recognized.
- "A quick rant about reality": In short, Graeme feels realism is overrated for games. He believes time is much better spent focusing on gameplay. You cannot "go wrong" with gameplay the way you can while attempting to achieve visual realism. He gave the example of Hollywood sets, which look real on film but have completely unnatural lighting environments.
- Lastly: "It's a game!" Graeme tells developers to "delight" their players, and create games that give them narratives to tell others the next day at the water cooler. He says that games that provide a narrative that can be easily described in words are the best.