They started by looking at the original game developed by Activision and Treyarch. Zombies is a extra mode of Call of Duty: World at War that was developed as a “lunchtime project” — a few developers threw it together on a whim, and enjoyed it so much that they released it as DLC, outside of the original game. So Ideaworks wanted to run with that vibe — create a game that you could play on your lunch break, or squeeze into a few minutes. They did find that the App Store tended towards more casual and family games, but they didn’t feel that the mature game could be successfully translated to a family-friendly format. Instead, they decided to stick with the blood and gore: “Activision,” Clarke joked, “said we would have to learn to love our 17+ rating, and live with not releasing in every country in the world.”

And they also wanted to create a game with “relaunchability,” a term that a developer at Treyarch coined. “What keeps you relaunching the game,” said Clarke, “is that, like most zombie games, you don’t really win. You’re just postponing your inevitable death.” He also said that learning became a big function of the gameplay — the game allows you to defend the same environment against zombies every time, so eventually you learn the best spots to make a stand, and so on.

Before development even started, they created a set of benchmarks in terms of performance and gameplay that they wanted to hit: Twenty zombies felt right for gameplay (you’d only be fighting 10 at any given time, but 10 more would be hanging around in the background), 20 FPS seemed like a good target for speed, 2000 triangles for graphics, and of course two thumbs (”the amount that most people have”) for control.

The controls were probably the most interesting part of prototyping — Clarke says his team really tried to brainstorm an interesting way to control an FPS on the iPhone. The problem, however, was that in an FPS game, you’re doing three things (running, looking, and shooting), but you only have two thumbs to do them with. One prototype they created had you tilting the accelerometer around to move (while looking and shooting with two onscreen controls), but for some reason, that made everyone who tested it rather dizzy. In the end, they went with a compromise, including a few different choices: a dual stick standard, an aiming assist system, and even a mode that only slightly uses the accelerometer to look around.

Authenticity was another question — obviously the iPhone doesn’t have the processing power of the latest and greatest consoles, so Ideaworks had to work hard to walk the line between keeping the game running smoothly and keeping it detailed enough to compare to the bigger title. They did a lot of pruning on the original model work, turning geometry into straight textures, and cutting off 3D modeling that couldn’t actually be seen by the player (the original team had even modeled tree roots underground, rendered on the Xbox 360 and Playstation 3, but never actually seen). They did things like not animating enemies when they weren’t in the player’s line of sight, and just using a sphere for the grenade hit model rather than actually modeling the shape, since it worked just as well. In the end, the iPhone had only about 1/7th of the geometry of the original game, but Ideaworks tried to make it at least look as similar as they could.

Multiplayer was a challenge, but fortunately, Activision had already created an online backend, so when Ideaworks hooked into that system, they were able to put together all of the multiplayer ideas they had (2-player, 4-player, and even a full online system) and then some (host migration was a project one of their engineers threw together in his spare time, and Bluetooth multiplayer was also added in on a whim).

Finally, Clarke shared a few lessons from the game’s development. In terms of the controls, they learned that offering a choice to the player is sometimes the right move, and when there is a choice, you usually need to force it at some point (if you hide a different control scheme in the options, most players will never find it). Piracy was something else they learned — while Clarke was hesitant to speak much about his opinions on piracy, he did say that it was easier to pirate the game than anyone on his team believed, and that in the first days of the release, they saw a significant number of extra users playing than had actually bought the game.

Still, Clarke said that the game had done very well — they’ve been high on the App Store’s Top Paid list ever since release, and while he didn’t mention sales for the main game, he said that the lite version has seen over three million downloads. Clarke’s panel offered up an interesting look behind one of the App Store’s big name hits.

TUAWGDC 2010: Call of Duty: World at War Zombies postmortem originally appeared on The Unofficial Apple Weblog (TUAW) on Wed, 10 Mar 2010 17:00:00 EST. Please see our terms for use of feeds.

Read | Permalink | Email this | Comments

Unit testing refers to a software validation methodology that allows programmers to test individual program units for correctness. It’s been an ongoing question in the iPhone developer community as to whether the iPhone’s view controller class is testable or not.

In response to these discussions, iPhone developer Jonah Williams has written up a view controller unit testing how-to over at the Carbon Five web blog. His write-up offers examples that show how to incorporate some best practices into your code.

Williams points out how broken NIB bindings are a common problem for iPhone OS applications. To address these issues, he regularly adds simple assertions that test that each IB outlet and action are set properly from inside his view controller class implementations. These assertions check that IBOutlet instance variables are not set to nil and that IBAction targets have been assigned, adding a layer of protection against broken bindings.

Another typical view controller issue involves responding to application memory warnings. To respond, he adds tests that ensure that each view-dependent property gets correctly released and re-created as views unload and then later reload. By building these into test methods, he can execute this behavior on demand, and ensure that the sequence will execute flawlessly in real world conditions.

Finally, Williams discusses view controller interdependencies. Often instances are tightly intertwined, with objects acting as clients for each other. For example, a simple table view controller, living within a navigation controller, might present a detail view via yet another view controller when a row is selected. That’s three separate controllers to account for, when you really only want to test one at a time. Williams suggests isolating these view controllers away from their interdependencies to test each component separately and provides examples of how you can do so.

What made Williams’ approach pop for me is how he carefully exposes and isolates dependencies for testing. These are features that can otherwise be hard to inspect and validate in the normal course of programming. His write-up is well worth reading through, and provides an excellent jumping off point for investigating view controller unit testing.

TUAWiPhone devsugar: Unit testing for iPhone view controllers originally appeared on The Unofficial Apple Weblog (TUAW) on Wed, 10 Mar 2010 16:30:00 EST. Please see our terms for use of feeds.

Read | Permalink | Email this | Comments

Unit testing refers to a software validation methodology that allows programmers to test individual program units for correctness. It’s been an ongoing question in the iPhone developer community as to whether the iPhone’s view controller class is testable or not.

In response to these discussions, iPhone developer Jonah Williams has written up a view controller unit testing how-to over at the Carbon Five web blog. His write-up offers examples that show how to incorporate some best practices into your code.

Williams points out how broken NIB bindings are a common problem for iPhone OS applications. To address these issues, he regularly adds simple assertions that test that each IB outlet and action are set properly from inside his view controller class implementations. These assertions check that IBOutlet instance variables are not set to nil and that IBAction targets have been assigned, adding a layer of protection against broken bindings.

Another typical view controller issue involves responding to application memory warnings. To respond, he adds tests that ensure that each view-dependent property gets correctly released and re-created as views unload and then later reload. By building these into test methods, he can execute this behavior on demand, and ensure that the sequence will execute flawlessly in real world conditions.

Finally, Williams discusses view controller interdependencies. Often instances are tightly intertwined, with objects acting as clients for each other. For example, a simple table view controller, living within a navigation controller, might present a detail view via yet another view controller when a row is selected. That’s three separate controllers to account for, when you really only want to test one at a time. Williams suggests isolating these view controllers away from their interdependencies to test each component separately and provides examples of how you can do so.

What made Williams’ approach pop for me is how he carefully exposes and isolates dependencies for testing. These are features that can otherwise be hard to inspect and validate in the normal course of programming. His write-up is well worth reading through, and provides an excellent jumping off point for investigating view controller unit testing.

TUAWiPhone devsugar: Unit testing for iPhone view controllers originally appeared on The Unofficial Apple Weblog (TUAW) on Wed, 10 Mar 2010 16:30:00 EST. Please see our terms for use of feeds.

Read | Permalink | Email this | Comments

Unit testing refers to a software validation methodology that allows programmers to test individual program units for correctness. It’s been an ongoing question in the iPhone developer community as to whether the iPhone’s view controller class is testable or not.

In response to these discussions, iPhone developer Jonah Williams has written up a view controller unit testing how-to over at the Carbon Five web blog. His write-up offers examples that show how to incorporate some best practices into your code.

Williams points out how broken NIB bindings are a common problem for iPhone OS applications. To address these issues, he regularly adds simple assertions that test that each IB outlet and action are set properly from inside his view controller class implementations. These assertions check that IBOutlet instance variables are not set to nil and that IBAction targets have been assigned, adding a layer of protection against broken bindings.

Another typical view controller issue involves responding to application memory warnings. To respond, he adds tests that ensure that each view-dependent property gets correctly released and re-created as views unload and then later reload. By building these into test methods, he can execute this behavior on demand, and ensure that the sequence will execute flawlessly in real world conditions.

Finally, Williams discusses view controller interdependencies. Often instances are tightly intertwined, with objects acting as clients for each other. For example, a simple table view controller, living within a navigation controller, might present a detail view via yet another view controller when a row is selected. That’s three separate controllers to account for, when you really only want to test one at a time. Williams suggests isolating these view controllers away from their interdependencies to test each component separately and provides examples of how you can do so.

What made Williams’ approach pop for me is how he carefully exposes and isolates dependencies for testing. These are features that can otherwise be hard to inspect and validate in the normal course of programming. His write-up is well worth reading through, and provides an excellent jumping off point for investigating view controller unit testing.

TUAWiPhone devsugar: Unit testing for iPhone view controllers originally appeared on The Unofficial Apple Weblog (TUAW) on Wed, 10 Mar 2010 16:30:00 EST. Please see our terms for use of feeds.

Read | Permalink | Email this | Comments

TapTime is on sale for free – normally $.99

The concept behind this game is nothing new and it’s not even all that interesting… tap on objects before they disappear from view, and don’t tap the one bad thing that will end your game instantly. The thing I love about this game, though, is the execution. The sound and graphics are both really well done and, overall, Andy Burke has put together a nice little time waster here.

TapTime is the kind of game that’s so basic a monkey could play it, but it’s also that very simplicity that will cause certain personality types to get hooked. The game also supports OpenFeint which is cool.

Grab this game while it’s free and give it a spin the next time you’re waiting at a bus stop, outside the principal’s office, or just completely bored out of your mind! It might surprise you.

iTunes Link – TapTime

MuscleNerd recently tweeted about a new device to boot tethered jailboken 3.1.2 iDevices without pluging it to a computer. This standalone piece of hardware is called an iDongle.

Now why would you need an iDongle? You might want to get one of those babies if your jailbroken iPhone or iTouch gets stuck at the “Connect-to-iTunes” logo everytime you reboot. The iDongle will save you a trip to the computer and can be very handy if you accidentally reboot your tethered device on-the-go.

According to the creator of the iDongle, this little piece of hardware is able to tether boot your jailbroken device, and optionnally jailbreak and hacktivate it if not already done. Looks like a savior for many of you who don’t want to be able to reboot your jailbroken iPhone anywhere/anytime.

What the catch? well the catch is that the iDongle is pretty much a prototype so far. It works but the creator needs your help to start manufacturing them in large quantities. You can help by buying a prototype at a good price, or simply by donating for a pre-order. I suggest you check out the iDongle website for more information.

In the meantime, watch this video to see see the iDongle in action. It’s a bit boring but it works!

What do you think about the iDongle?

“iDongle Boots Your Tethered 3.1.2 Jailbroken iPhone” is an article by the iPhone Download Blog sponsored by the iPhone Store. Feel free to leave a comment or discuss this topic in the forum. For the latest iPhone info, don’t forget to follow me on Twitter.

How addicted are you to your iPhone? Addicted enough to express it on your fridge with some iPhone app magnets? If so, check out the iPhone App magnets from Jailbreak Toys.

The magnets include the entire first iPhone home screen, including the newer “Messages” app instead of “SMS”. The only two missing apps are Voice Memos and Contacts.

The set costs $12.99USD with free shipping with the purchase of three or more sets. The magnets are rather cool looking and would make a great gift for that iPhone fanatic in your life, but there is only one problem…no
Canadian shipping!

At this time, it seems they only ship to US states, even though “Postal Code” is listed as a required input field. There are ways around this limitation, but it’s too bad that there is not a direct Canadian shipping method.

[Jailbreak Toys]

Addicted To iPhone? How About Some iPhone App Fridge Magnets is a post from: iPhone in Canada Blog - Tips, Tricks, News, and Tutorials for Canadian iPhone Users