thedoedoeblog

Musings of a small game development team

Evolving Challenges of Casual Games

Written by Dane Baker on April 11, 2009 at 3:19 pm

Once a race to produce the most visually realistic titles, today’s games industry is courting perhaps the most diverse audience ever — Nintendo’s Wii and DS handheld proved just how successful a game publisher can be in targeting this diverse audience, even to the detriment of the competition (witness Electronic Arts’ recent troubles, which can be blamed in part on their failure to embrace Nintendo’s platform).

Those who pick up a Wii controller or even a PSP handheld expect to devote a certain chunk of time to playing games; even the most casual titles deliver a certain level of experience and accompanying learning curve. Enter Apple’s iPhone, which is redefining the category even further: iPhone users rarely “sit down” to play an iPhone game, no matter how engaging — they play waiting in line at the post office or during a quiet moment at work or while writing blog posts (just kidding). This isn’t to say there’s no room for more structured, traditional games — Subatomic Studios’ super-successful tower defense title Fieldrunners comes to mind — but for many iPhone developers, “casual” is taking on a new meaning.

Apple recently released a list of the top 20 paid apps (link launches iTunes) — of those, 15 are games, most of which can be launched and delved into in mere seconds. Generally speaking, this has no effect on game quality, but it does present unique challenges to iPhone developers. Namely, creating an experience that is familiar with little or no learning curve yet interesting despite abrupt pauses in gameplay.

This early in the iPhone lifespan many games’ uniqueness turns on interfaces and control schemes that utilize the iPhone’s unique features (accelerometer controlling character movement, for example). As the App Store begins to mature, developers will be able to rely on such simple solutions less and less; hardware features will change, as will user expectations. The challenge will be how best to provide a more varied experience — using the accelerometer to control one aspect of movement while touch gestures control another, for example — that can still be picked up and enjoyed almost instantly by the end user. Even now, with the third iPhone interation on the horizon, gamers expect a certain level of novelty; witness the tepid response of Konami’s Metal Gear Solid Touch, which provided simplistic touch-to-shoot gameplay that elicited mostly yawns from critics.

Obviously change of this sort will happen gradually as the iPhone market ages. The winners of tomorrow will be the developers who can adapt the quickest to meet these evolving challenges head on.

Scraping iTunes: Finishing Up

Written by Bill Soistmann on March 26, 2009 at 1:03 pm

Last week I started a series of posts detailing how I scraped the iTunes store and how you might do the same for your needs.

Today I will add just one last thing and we will call this a wrap.

Continue reading Scraping iTunes: Finishing Up  »

Scraping iTunes: Touch of Generalization

Written by Bill Soistmann on March 23, 2009 at 7:06 pm

At this point our script (if you haven’t been following along) gives us the xhtml for five images which we can include in our webpage. This works nicely but requires that we name and store our images a certain way. What if we want to use different image names?

Continue reading Scraping iTunes: Touch of Generalization  »

Scraping iTunes: Returning HTML

Written by Bill Soistmann on March 20, 2009 at 11:50 am

Today I want to take a look at how to modify our Perl script so that it returns the html we need instead of a number. The current version of our script can be found here. Before I get ahead of myself, I want to mention that we will continue to ignore the country code for now. Adding an option for grabbing the data from another iTunes store adds quite a bit of code so I will cover that in my last post.

So what we want to do today is add an option for grabbing the data as html instead of a number. It makes sense to leave the number as an option in the event someone still wants to use it for that purpose. At this point, we know we can add two arguments to the URL

Continue reading Scraping iTunes: Returning HTML  »

Scraping iTunes: Deciding Direction

Written by Bill Soistmann on March 19, 2009 at 7:18 am

I finished off my last post by sharing a Perl script which will output the number of stars for an application given the app id. Today I will explain what I hoped to accomplish when I came up with the idea and then the direction in which I ended up moving. Feel free to grab the script and use it for your own purposes.

For the sake of demonstration, let’s look at an example using 3½ stars.

Continue reading Scraping iTunes: Deciding Direction  »

Older Posts »