Why would a three-year-old want to play games on an iPhone? Actually, let’s re-think that—why wouldn’t a three-year-old want to play games on an iPhone?

iPhones and iPod Touch devices are extremely attractive to small users in the three- to five-year-old snack bracket. These devices are easy for small hands to use—much easier than computers, keyboards and mice. Children can also use them anywhere. Think of the possibilities: while waiting in line with you, while traveling or commuting, in the car, during quiet moments at home. Anytime your child is looking for an activity. Anytime you’d like your child to be engaged and interested instead of frustrated or bored and distracted.

But if you’re going to hand over your iPhone or iPod Touch to your child to play with, you’re going to need some entertaining apps for him or her to play. That’s where Tickle Tap Apps come in. Tickle Tap Apps are age-appropriate educational games that encourage learning through practice and exploration. They take full advantage of the iPhone platform in ways that make game play exciting. They’re also easy to use, with audio instructions and visual cues so preschoolers can pick them up and start playing right away.

The first three Tickle Tap Apps will be available very soon from the iTunes App Store. Visit TickleTapApps.com to learn more. Plus get sneak peeks at game play by watching demo videos of Sound Shaker, Count Caddy and Sort Slider.

@jasonkrogh asked what kind of units Box2D uses. Here’s the relevant bit about units from the Box2D manual:

Box2D works with floating point numbers, so some tolerances have to be used to make Box2D perform well. These tolerance have been tuned to work well with meters-kilogram-second (MKS) units. In particular, Box2D has been tuned to work well with moving objects between 0.1 and 10 meters. So this means objects between soup cans and buses in size should work well.

When you’re working with on screen objects like balls and squares, what’s important is that the units are not pixels.

@satefan asked:

For my little demo I set the dimensions of the world to 320 meters wide by 480 meters high. This seems to work fine and I don’t have to do any coordinate translations. Just curious… was there a reason why you decided not to do this?

The short answer: the physics won’t look right because your bodies and shapes will be much larger, heavier and faster than Box2D is expecting. Here’s what the manual has to say:

Being a 2D physics engine it is tempting to use pixels as your units. Unfortunately this will lead to a poor simulation and possibly weird behavior. An object of length 200 pixels would be seen by Box2D as the size of a 45 story building. Imagine trying to simulate the movement of a high-rise building with an engine that is tuned to simulate ragdolls and barrels. It isn’t pretty.

Let’s do the math for the the balls in the example game on the iPhone. If we set the world size to match the screen, then the world would be 320 meters across, 480 meters tall and 1 pixel on screen would equal 1 meter in Box2D. If the ball had a diameter of 64 pixels (which is does), it would have a diameter of 64 meters in the physics engine – that’s pretty small on screen, but more than six times the size of Box2D’s recommend 10 meter maximum.

Here’s an example of where this becomes a problem: Box2D has setting for the maximum velocity any body can have and the default value is 200 meters per second (you can see all of Box2D’s settings in b2Settings.h). Because things are so big, they’re also very heavy (think about how much a 64 meter wide ball would weigh!). To make them move, you have to crank gravity way, way up and apply a lot of force. You quickly run into the limit and everything ends up moving around at the same speed (which looks terrible, trust me). Rather than fiddling with the (many) settings, the best thing to do is a simple translation between screen coordinates and world coordinates:

// MyGameViewController.h

#define SCREEN_TO_WORLD(n) ((n) / 30)
#define WORLD_TO_SCREEN(n) ((n) * 30)

In the macros above, 30 is an arbitrary value. The idea is to choose a value that will convert the size of an object in pixels to a value that falls in the 0.1 meter to 10 meter sweet spot. By dividing the ball’s 64 pixel screen diameter by 30 in the SCREEN_TO_WORLD macro gives it a diameter of 2.13 meters in the world. What is a relatively small object on screen is now a relatively small object in the world – it also weighs less, so you can use smaller forces and don’t run into the maximum velocity limit.

Just make sure that any time you set any linear value (position, size, force) in the world, convert from screen coordinates to world coordinates. When you read any linear value from the world, convert from world coordinates back to screen coordinates. I like to use custom accessors to make it easier:

// Ball.m

- (CGPoint)position {
  if([self body]) {
    return CGPointMake(
      WORLD_TO_SCREEN(body->GetPosition().x),
      WORLD_TO_SCREEN(body->GetPosition().y)
    );
  } else {
    return CGPointMake(
        WORLD_TO_SCREEN(bodyDef->position.x),
        WORLD_TO_SCREEN(bodyDef->position.y)
    );
  }
}

- (void)setPosition:(CGPoint)aPosition {
  NSAssert(![self body], @"Cannot set position");
  [self bodyDef]->position.Set(
    SCREEN_TO_WORLD(aPosition.x),
    SCREEN_TO_WORLD(aPosition.y)
  );
}

When developing iPhone games, one of the biggest performance optimizations you can make is to use OpenGL ES for rendering (instead of CoreGraphics or UIKit). For a 2D game like Arctic Shuffle, this means loading all of the animation into Open GL as textures, and drawing them onto simple rectangular shapes.

There are two caveats to this approach. First, disk access on the device is dirt slow, so you can forget about loading textures on the fly – all of the textures need to be loaded before gameplay begins. Second, OpenGL ES on the iPhone has a texture memory limit of 24MB. If you try to load more than 24MB of textures (including any buffers, like the framebuffer), the device has to start swapping them in and out of memory, and you go over a performance cliff, so to speak.

With that in mind, it’s very helpful to know how much texture memory is being used by your game – this is where Instruments comes in (the instructions below assume that your device is plugged into your development machine and you already have a working debug build of your game on the device).

1. Open Instruments (/Developer/Applications/Instruments.app) and choose the “Blank” template.

2. In the bottom-left corner of instruments, click on the gear icon, then choose Add Instrument > Memory Monitory. Click the gear icon again and choose Add Instrument > OpenGL ES.

3. Click on the OpenGL ES instrument’s info icon, and make sure that GARTResident Object Size is checked.

4. Choose the device and application you wan to check. My device is named Barracuda and the application is ArcticShuffle2.

5. Click the record button. This will launch the application on the device, and start monitoring it’s memory and OpenGL ES usage. The GARTResident Object Size column shows the amout of texture memory used, in bytes. Divide that by 1024 (i.e. amount / 1024 / 1024) to convert the number to megabytes. Notice how the Frames Per Second drops dramatically while the textures are loading.

Happy Optimizing!

When we’re weighing feature ideas they have to pass through a few basic filters – how long will it take to implement? will it have an adverse affect on another aspect of the game? will it translate into happy players (read: sales)?

I’ll cut to the chase and share a few of the items that are on our ‘no-brainer’ list:

• performance: we’re rewriting it all to use openGL which will go a long way toward addressing the ‘laginess’ of the current version.
• scoring system: once you unlock a level there’s not a whole lot of reason to go back and play it again. The next version will award a score based on how quickly a level is cleared and how many penguins were used.
• launching UI: it’s very hard to get a sense of the power of your shot in the current version because the information you need is obscured by your finger. We’ve drawn up half a dozen ideas on how to improve on this. Now we just have to pick one.
• better help: we hate help. we like to just play and learn by doing. Apparently not everyone is like this so we’re going to expand on the help to explain more explicitly how some of the obstacles work.
• keep the tunes rolling: this is our bad. the current version of the game stops your tunes when it launches so there is no way to listen to your own playlist while you play. Maybe you like boy band action with your penguins or maybe a little Einstürzende Neubauten? Who are we to stop you?!

Of course there are many more items on our list – more obstacles, more sophisticated collision detection, power ups and other fun stuff. Now we just need to see how many of them we can cram into the next few weeks of development.

Arctic Shuffle Sneak Peak from Jason Krogh on Vimeo.

http://sxsw.com/peoples-choice