Aspect Ratios & Camera Behavior
It’s no secret that I’m working on a new iOS game. (Nope, not Mimeo, still don’t feel like I have the chops to pull that off. Yet.) While I haven’t said too much about it yet, like Mimeo, the new game is a 2d platformer targeting both the iPhone/iPod touch and the iPad. The different aspect ratios of the two device types present some unique challenges when designing levels. (Development is overlapping with a number of other projects/responsibilities so I’ve been lax in my development diary duties for this game. *dusts off blog*)
Levels come in four varieties: a single screen tall and wide (room), a single screen tall and multiple screens wide (corridor), a single screen wide and multiple screens tall (shaft), or multiple screens wide and tall (cavern). Like The Last Rocket the new game has an 8-bit aesthetic so a screen on an iPad is 256x192 pixels and 240x160 on an iPhone (both scaled squarely to exact device resolution).
Obviously, a single iPad screen won’t fit on an iPhone screen without the camera drifting vertically on corridors, horizontally on shafts, or both in rooms and caverns (vertical drift can be minimized with the use of a trap). The Last Rocket sidestepped the issue with single iPhone screen sized levels and a tile set that resolves to black so the unused area of the iPad screen is unnoticeable.
The solution I’ve decided on requires a slightly modified camera behavior and that some simple rules be observed when designing levels.
The camera still follows the trap (instead of the player character) but on the iPhone the camera is snapped to a special bounds rectangle—unless the player character moves beyond that rectangle. The bounds rectangle is four rows and two columns smaller than the level and offset by two rows and one column from origin.
Look familiar? On a single screen room, the relationship between the level and the bounds is the same as the relationship between the iPad and iPhone screens. So what happens when the player character moves beyond the bounds? The camera slides to its natural, unsnapped position using the player character’s current velocity (or a default value when stationary).
The level design considerations are easier to explain. To ensure that an edge is always visible on screen at the edges of a level, the top and bottom three rows and two columns on the left and right must be solid (with obvious exceptions for the doors that connect levels). I also block out some persistent space for the player’s thumbs (but not on screen buttons!). More on that in another post.
