First person shooters frequently demand three different basic actions be performed at the same time time: moving, looking, and shooting. On a PC, the keyboard is usually used to move, and the mouse to look and to fire. On a console gamepad, two analog sticks are used to move and look, and shoulder buttons are used to fire. Both setups allow for all three actions to be done at the same time. The PC setup allows for far more precise aiming, while the console gamepad setup allows for analog movement.
When playing a game on the iPhone by holding the device in a landscape orientation, the setup allows for two on-screen elements to be feasibly interacted with at the same time, both of which involving thumbs. The thumbs are most comfortable in the bottom corners, and can go to the top corners fairly easily.
Thumbs obscure anything they touch.
The accelerometer can be used as a third input. Rotating the device moves the screen around, which is obvious but needs to be considered before giving the accelerometer any role in controlling the game.
Because of these considerations, the iPhone is fundamentally at a disadvantage. If the accelerometer is not used, the user can only do two of the three basic actions at a time. Using the accelerometer brings with it its own set of considerations.
The remainder of this post will list various options for controls, and weigh pros and cons in each.
If a game has several controls relegated to the corners, the parts of the screen that don't have controls can be used for another action.
See: Prey Invasion
In the tap to shoot mechanic, the player can directly tap on bad guys to shoot them.
Pros: Very quick to fire at an enemy, possibly even faster than with a mouse.
Cons: The thumb obscures the target, leaving you generally without visual feedback of the damage you're inflicting or any changes in the situation around the bad guy (such as if he fired a rocket at you while you were shooting him). Also, the thumb is fairly large, so some degree of aiming assistance might be needed (should register a hit so long as the bad guy is covered by the thumb, not just when the bad guy is precisely at the center of the thumb). The visual feedback problem might be able to be helped with a loupe: an extra viewport placed above the thumb that shows what the thumb is covering.
See: Brothers in Arms, Terminator: Salvation
The mouse pad mechanic allows the user to treat the screen like it was a mouse pad, and their thumb like it was a mouse.
Pros: High precision, frees up the screen from having a separate look control.
Cons: Thumb obscuring can be a problem if it goes too far without being lifted. Can be frustrating without a well-refined acceleration curve.
In addition to a single fullscreen control, multiple smaller controls can be placed on the screen.
See: Just about every FPS on the phone
This replicates a console-style analog stick, but on the touchscreen.
Pros: Intuitive, straightforward, works pretty darn well
Cons: Any virtual analog stick needs to be highly refined to deliver a good experience. Dead zones, acceleration curves, the size of the control, etc are all easy to screw up. In summary: difficulty of implementing well.
See: Wolfenstein 3D, iFPS
This is the same as the movement stick, except for looking.
Pros: Intuitive and straightforward. Works pretty well in practice when done correctly.
Cons: More or less all of the difficulties of the movement stick. Not the most efficient way to look. Precise aiming can be tricky if the stick is too sensitive. Turning broadly can be hindered if the stick is not sensitive enough.
See: Not aware of any on the phone
This is the same as the full-screen mouse pad, except limited to a small area of the screen.
Pros: Precise. Allows the screen to be used for a different purpose, like tap to shoot.
Cons: More likely to be finicky than the full-screen mouse pad.
See: Just about everything
It's a button. Tapping it fires your weapon.
Pros: It makes things die.
Cons: Why can't we be friends?
See: Not aware of any on the phone
Tapping this button causes your view to lock onto a nearby enemy, either for a prolonged period, Metroid Prime-style, or just at the moment you tap it, Call of Duty-style.
Pros: Big help to aiming when combined with less precise looking options.
Cons: Not as helpful for weapons that need to be led (like rockets) as it is for instant hit weapons. Exists to cover the fact that your general aiming method isn't precise.
The only way to allow the user to realistically do three things at once is to use the accelerometer. But it's really easy to screw up, so be careful if you use it.
See: Cube
This control scheme turns the phone's accelerometer into an analog movement stick. It is also morally equivalent to using infants as a baseball bat.
Pros: None that I will dignify by listing here.
Cons: Just about the most backwards thing ever. Also, I'll not want to be your friend.
See: Several games have this as an option
This control scheme turns the phone's accelerometer into an analog looking stick. It's like tilt to move, except it actually makes rational sense.
Pros: Given on-screen movement and shooting controls, the user can do all three basic actions at once.
Cons: Same considerations as all other analog schemes. Tilting the phone alters the view angle of the screen. Special consideration to sensitivity and neutral angle is needed.
See: Doom Resurrection
This is distinct from tilt to look in that tilting doesn't change where you're looking, it just moves the crosshair within the viewport.
Pros: Works very surprisingly well.
Cons: Not a complete solution to the looking action. The game needs to either eliminate looking as a full-fledged action (as in an on-rails game like Doom Resurrection) or have a separate on-screen looking control to control broad turning.
See: Not aware of anything on the iPhone, but Metroid Prime 3 on the Wii is pretty close
This combines looking and aiming into one control. The more you tilt the phone, the faster your character will turn and the further off-center your crosshair will be.
Pros: If done well (like Metroid Prime 3), it works pretty well.
Cons: If done poorly (like many other first person shooters on the Wii), it'll just be awful.
There are many options available to developers, and I don't think anyone has hit the sweet spot yet, though id has delivered very good experiences in both Wolf 3D and Doom Resurrection. This post didn't even touch on things like jumping and switching weapons, but it's long enough as is. I think the iPhone has the potential to be at least a satisfactory player on the FPS scene. It's just a matter of figuring out the controls.
Take a look at Blizzard's modern games: Warcraft, Diablo, and Starcraft. They all involve various numbers of characters with attributes and abilities and whatnot. Pretty much every aspect of a character can be modified by buffs, talents, consumable items, researched tech, etc. These modifications can do pretty much anything, from granting a character infinite breath underwater to making a fireball spell bounce on the ground multiple times to unlocking or preventing the use of entire abilities. Sometimes the modifications stack, increasing effectiveness with each level in the stack. Sometimes different modifications impact the same aspect of the character (you might have five different equipped items increasing a character's agility, plus three different buffs cast on him that also increase agility).
The problem that I want a solution for is how do you support this logic. Essentially, an entity (like a character) wants to ask an arbitrary set of objects to mutate some property or a set of properties that the entity exposes.
The Chain of Responsibility pattern is the closest I can find. You create some sort of request object ("What should my agility be?") and then toss it down a chain of objects that say they can mess with agility. They each get an opportunity to mutate it, and then once the chain is complete the request has been resolved.
It seems to me, however, that the desired cases want something a bit more than that. Depending on some conditions, the behavior of the objects in the chain could be different. You might want to sum up the values of agility producing objects, or select only the highest speed buff from objects that present different speed values.
It's things like the extra combinatorial logic that's kind of tripping me up. Anybody know of anything that would fit the bill, or am I looking at just an ad hoc augmentation and specialization of the Chain of Responsibility pattern?
Edit: Actually, maybe the mediator pattern? I dunno, I'm tired.
While it might be a bit tricky to follow so much data, the gist of it is thus: Sunset on the iPhone 3G constitutes some level of awesomeness (or LOA), let's say one unit. Sunset on the iPhone 3G S has a higher LOA due to its shorter loading time. In fact, and perhaps counterintuitively, as the loading time decreases, the LOA increases by the reciprocal of the decrease (one half the loading time equals two times the LOA). Therefore, we can see that the iPhone 3G S causes Sunset to have two units of LOA, a 2x increase over the iPhone 3G. I will leave it to the reader to consider that as the loading time approaches zero, the LOA approaches infinity. Or, in other words, it approaches Chuck Norris. And like how the loading time can never actually reach zero, likewise can the LOA never actually reach infinity, AKA Chuck Norris' LOA.
The second is the use of a cache manifest file which cuts the initial load time in half, and as far as I can tell actually allows you to load and play Sunset entirely offline. In other words, after you've saved the game to your home screen and launched it at least once, the game is installed and you can play it anytime, even when you don't have an internet connection. Cool, huh?
The Home Screen version of Sunset has received a few tweaks to deliver a better experience on iPhones and iPod touches. First, the browser controls are removed, and the added real estate is spent on a larger game view area. Second, the control pad now responds to touch events, rather than onclick events, which makes it much more responsive. In addition to responding to touch events, the control pad also now has pressed states for each of its buttons, which adds just a bit of an extra tactile feel to things.
Try it out!
Not a bad set of announcements today. I like how many of them aren't even trying for something revolutionary and huge, but are rather trying to toss in a million little refinements to make things faster, cleaner, and just overall better.
I'm thinking about playing with some of the more recent improvements in WebKit. When I first started developing Sunset, Mobile Safari didn't give a lot of love to iPhone developers. No way to intercept touch events, pretty dismal performance, etc. Things have improved quite a bit since then. So much so, I dare say, that talented developers could make webapps that are now only a half step shy of their native counterparts in terms of at least delivering a decent touch interface.
Maybe I should make a refined version of Sunset, one that just goes a bit further with the WebKit stuff.
The app is sort of a digital picture frame that streams its photos in from various sources off the internet. The Facebook integration is particularly cool.
One of the first things I did was create a utility that could "compile" a level, which was the process of generating a quadtree from the level geometry, and then determining visibility between leaves. Also, collision detection was computed. The screenshot up above (click for a fullsize image) is from the level editor I wrote. Light green squares are solid, white squares are passable. The red lines show the quadtree, and the entire map image is tinted based on visibility (tinted areas are invisible from the position of the camera (represented by the blue arrow/carrot thing)).
As an added bonus, the screenshot also shows a few of the new textures, and the preview window is fairly representative of what the actual game will look like, so this constitutes the first media release of Sunset :D.
Anyway, the original game renderer was heavily focused on rendering as little geometry as possible, and it did this by rendering only the walls that were visible according to the compiled level data set. This was a fairly complicated bit of code, and it proved to optimize the wrong thing when the goal was performance. With geometry as simple as the levels in Sunset, it was actually faster to just render the entire level in one shot, going from one draw call per texture per visible leaf, to just one draw call per texture for the entire level. I would've saved myself a lot of work if I just tried that simpler road from the beginning.
Another example involved drawing bad guys and other sprite-based entities. Because of the way that OpenGL works, geometry for sprites must be drawn back to front (the furthest away bad guys first). For every single frame I build a list of visible entities (which, incidentally, I determine via the dataset I computed earlier for level geometry visibility, I guess that work wasn't a total wash) and then sort the list based off the distance from the entities to the camera.
Because of how frequently the distance between entities and the camera is calculated, I figured the method that computed it had to be really fast, so I employed a common trick when only an approximate distance is needed: I omitted the square root. This resulted in the ordering of entities being correct about 98% of the time. Sometimes, if entities were at just the right spot and moving in just the right direction, you could see them ordered incorrectly for about a quarter of a second. I figured that slight inaccuracy was worth the speed boost.
Well, just recently I decided to do things "the right way" just for giggles, and began computing distances complete with square roots. The result? Entities are always ordered correctly, and there was no qualitative drop in performance. Premature optimization, how foul.
I think Donald Knuth should insist on being called "Don."