« Back to Mobile Game Contest page
Defining Quality Games
- Aesthetics and Scalability: Graphics optimized for mobile device; Text/Instructions/scores, clearly legible; buttons large enough to use on touch screen.
- Usability: Game works regardless of input options (keyboard, touch screen, accelerometer, etc), easy to navigate and play; pause/save options; intuitive; seamless landscape, portrait, and full screen display; leverage and understand the device.
- Performance: Loads fast, built at 25-30 frames/second, fast start up time.
- Creative and Marketable: Addictive, unique, can be adopted across multiple audiences.
- Framework: Built with standards in mind; easy to adapt to other displays quickly with minimal recoding effort; device and player detection, opportunity to integrate with social media.
- The content fits on-screen appropriately (content almost fills the entire browser window before going to full-screen without over-filling it. The user
shouldn’t have to swipe the content for example, in order to hit the PLAY button).
- No more than two mouse-taps should be required before game play begins
- Text should be clearly legible on a mobile device – 18 pt. type. (Reference Flash Sizing Zen for more help)
- Sound/audio — should be a way to mute sounds, but volume control should be unnecessary, sounds should be appropriate for mobile device (for example, one game has an explosion sound that just sounds like static on a phone).
- If the game is designed for landscape or portrait, then the screen orientation should be locked in appropriately (see Flash Sizing Zen document for more information) – but at a minimum the user should receive some type of prompting if they are in the least favorable orientation.
- Go automatically to full-screen mode on selection, pause the game if leaving full-screen mode, and hitting resume re-invokes full-screen mode, is okay to leave full-screen if text input is required.
- Game must be uploaded in SWF format
- If there is a desktop SWF and a mobile SWF, the user should be directed to the appropriate experience
- If the game file size is greater than 400K, utilize pre-loader should be part of the experience.
- If the user must receive UI hints (what objects they can pick up for example, should use finger-down type hinting or (select-object-with-feedback then a secondary interaction specifies the action on that object) as opposed to mouse over hinting).
Aesthetics and Scalability:
- Buttons are large enough and have a large enough hit area (66 x 66 pixels for the hit area).
- Auxiliary screens, such as instructions, should be legible on a mobile device (18 pt minimum font size).
- If optimizing an existing game, this means that the game might have to see a change in layout or have a simplified gameboard to make sense on mobile.
- Game 'cells' or anything that is clickable/tappable should be no smaller than 60 pixels on a mobile device.
- Links to external content (e.g. more games) replace existing content (might also consider leaving full-screen mode before referencing URL) – they DON’T launch content in a pop-up (
- If the user doesn’t have FP 10.1 installed, then they are presented with the option to install/update the Flash Player 10.1, and acting on that option takes the user to the appropriate page
- Assets designed and/or tweened in Flash CS4 or CS5 should be optimized for mobile