The iPhone gaming Fallacy

Recently I’ve had a lot of discussions about how good the iPhone/iPod touch is for playing games on. Most people contest that, unlike a traditional handheld console, the iPhone is limited by it’s control mechanism. That is to say, there are no physical buttons. I don’t agree, I see the iPhone’s control mechanism as something that makes it different, not something that makes it inferior. The reason for this is very simple, and can be seen by splitting up games by genre. I’m going to look at several game genres, and which platforms play them well.

First Person Shooters

FPS games need the ability to turn fast, and perform lots of interesting actions. In reality, the most important requirement here is being able to spin on the spot. This is something that mice are *incredibly* good at. They provide the ability to move extremely precisely to any point, and at any speed you require. For that reason, along with there being over a hundred buttons on a keyboard, PCs have to take the crown in this department. But I was talking about hand helds. Which of those takes the crown here? An analog stick doesn’t give you the fast precision of a mouse, a touch screen can simply let you tap where you want to turn to. I’ve not though seen any fps games implemented this way yet, they all try to simulate an analogue stick for some silly reason. On the other hand, traditional controls have plenty of spare buttons to use for fire, jump etc. A touch screen has no such luxury. For this reason, I’m going to give FPSes to the traditional console.

  1. Desktop PCs
  2. Traditional handhelds
  3. Touchscreen

Racing Simulations

Racing simulations require a smooth, analogue input that mirrors a steering wheel well. There really is no contest here, traditional handhelds have the perfect control mechanism! PCs similarly gain the perfect control mechanism, as long as you attach a steering wheel.

  1. Traditional handhelds
  2. Desktop PCs
  3. Touchscreens

At this point, things aren’t looking too good for the poor old iPhone, but lets carry on with some more game genres

Role-playing games

Controlling a character in a role-playing game for example is done quickly an easily with an analogue stick, though often selecting enemies to fight can be a chore. With a touch screen, we can tap where our character should go, and we can tap on enemies and actions to have a punch up. This one’s close, but it’s got to go to the Touchscreen. A side note though – the PC, with it’s combination of keyboard and mouse can do this better.

  1. Desktop PCs
  2. Touchscreens
  3. Traditional Handhelds

Strategy

Strategy games require you to be able to pick units quickly, and give orders out fast. That means being able to select something on the play area near instantly, and then direct the something somewhere else on the play area similarly quickly. The touchscreen is a clear winner here, you can simply tap units, and drag/retap them where they must go. With a traditional console, we must sit pushing buttons repeatedly to select the right area of screen. With a PC, we at least have a mouse with which we can quickly point to the relevant units and move them.

  1. Touchscreens
  2. Desktop PCs
  3. Traditional Handhelds

New Genres

The iPhone seems to have spawned a whole new genre of game – the line drawing game. Be it Flight Control, or 33rd Division, all of these games involve lots of things moving about the screen, and you drawing out lines to control where they go.

Conclusions

That’s by no means an exhaustive list of game genres. What we’ve hopefully seen though, is that the iPhone is not an awful platform for gaming. It doesn’t do so well on some game genres that traditional handhelds excel at, on the other hand, it does extremely well for other generes, and has even invented whole new genres specifically for it’s input mechanism.

Advertisement

Obj-C’s type system is too strong

That’s rather a surprising title, isn’t it! Objective-C has one of the weakest type systems of any language. What I’m going to demonstrate though, is that with the addition of Objective-C’s “block” construct (really closures with a special name), Objective-C’s type system is now not only too weak for my tastes, but too strong to do useful things!

In short, Objective-C’s type system is broken, not only does it allow lots of incorrect programs that many type systems disallow, but it also disallows a fair number of correct programs that it shouldn’t.

Blocks

Objective-C gained a really useful feature lately – the closure. We can define a closure like so:

// Define a closure that multiplies it's argument by a variable 'a'.
- (void)myClosureDefiningMethod
{
    int a = 5;
    int (^timesA)(int x) = ^(int x) { return x * a; };
}

The syntax isn’t the prettiest in the world, but it mirrors C function pointer syntax, so it’s not all bad.

Higher Order Programming

The ability to create functions on the fly like this is really powerful, so much so, that whole languages (like Haskell) base their programming style on doing this kind of thing lots. Let’s then, turn to Haskell for inspiration about what kinds of things we might want to do with this.

The standard Haskell library (the Prelude) defines some really stunningly simple things using this technique, and the lovely thing is that they turn out to be quite useful. Lets look at const for example:

const :: a -> b -> a
const x y = x

So, we pass const an argument, and what we get back is a new function that ignores it’s argument, and returns our original one. It’s dead simple, but mega useful.

Lets try to define the same function with Obj-C closures then:

(a (^)(b ignore))constantly(a ret)
{
    return ^(b ignore){ return ret; };
}

This looks great! We have our const function, but wait, I’ve cheated. I’ve not defined the return type of the closure, or the type of constantly’s argument properly. What I want to be able to say is, in typical C weak typing fashion, “any type at all”. This, although it wouldn’t specify the type very strongly, would at least allow me to use the function. Unfortunately, neither C, nor Obj-C has such a type. The closest you can reasonably get is void *, and that won’t admit a whole swathe of useful types like BOOL, int, float etc.