You know that killer new app you just got for your iPhone? Could you beam us a copy to try? Of course you can't -- it doesn't work that way -- but someday soon it might. The fine folks at Patently Apple recently unearthed an Apple patent app that describes a way to transfer apps over peer-to-peer Bluetooth or shiny, star-filled WiFi. The idea goes that if a company wants to spread a program by word of mouth, it might as well make it shareable too, and so the owner of an app could transfer an "application seed" to friends and associates with a similar device. You'd pick from a menu of apps to beam over, where only those greenlit by their developer would be available to send, and your recipient would receive a trial version -- or somewhat less excitingly, a link to the App Store -- over the air. The patent app suggests that recipients could even share the demo in turn, generating generation after generation of word-of-mouth sales, and that companies might even reward particularly influential sharers in some way. What's that rumbling we hear? Just the gears turning in the minds of men plotting the next great pyramid scheme.

Waiting in line for movie tickets is still the worst part of going to the movies (unless you are going to see The Bounty Hunter). With so many mobile phone movie apps, it’s easy to find what’s playing at nearby theaters and even purchase tickets right from your mobile phone, but then you still have to get a paper ticket from the dispenser or the ticket agent. But your ticket could easily be delivered to your mobile phone via a 2D barcode.

Today, Fandango is launching a mobile ticket program in eight cities which lets moviegoers finally go paperless. Your ticket is delivered to your mobile phone in the form a of a 2D barcode, or QR code, which the ticket-takers can scan. Movie theaters need to equip their attendees with special scanners, which is why it is only available in a few markets. (MovieTickets.com is testing a similar program).

Here are the theaters participating in Fandango’s initial rollout:

• New York: City Cinemas 1, 2 & 3, Angelika Film Center, East 86th Street Cinemas, Village East Cinema, Beekman Theatre, The Paris Theatre.
• New Jersey: Manville 12 Plex.
• Houston: Angelika Film Center.
• Dallas/Plano: Angelika Dallas; Angelika Plano.
• San Diego: La Mesa Grossmont Center, Clairemont Town Square Stadium.
• Bakersfield: Valley Plaza 16.
• Sonoma County: Rohnert Park 16.
• Hawaii: Ward Stadium, Kahala Theater, Kapolei 16, Mililani Stadium.

CrunchBase Information

Fandango

Information provided by CrunchBase

Mimeo and the Kleptopus King

As anyone on Dribbble already knows, I have been hard at work on my next iPhone/iPod touch game for the past two months. With the public launch of Dribbble imminent (I haven’t heard anything more than “soonish”) I thought the Mimeoverse could use a proper introduction.

Early last year, I applied for a MakeWork grant from local Chattanooga arts initiative CreateHere. In May (thanks in part to generous recommendation letters from the talented Messrs. Marcotte and Rubin and some handsome illustrations by Mr. Cornell) I was awarded partial funding for my proposal to create a faux 16-bit game engine. My new game designs are far more ambitious than my inaugural effort, Horror Vacui, aspiring to multiple worlds and levels, various unique power-ups and hand-crafted pixel graphics, all of Super Nintendo caliber.

A few months after the release of Fever I started on the engine. This past December I took a whole week off from support to make one last uninterrupted push and finished the core components of asset management, audio/visual output, a unique touch-based input method, and tile-based animated sprites and maps. I also built out an HTML-prototype map editor. It may sound like I took a vacation to get some work done but when you’re doing what you love, it’s really not work.

A simple proof of concept was required to iron out any kinks in the finished frameworks. That concept proved more interesting than the original game I set out to create.

Pushing Pixels

Before I get to Mimeo, I want to address my love of pixels. The aesthetics of Mimeo (and Horror Vacui before it) are not born solely from nostalgia. Good pixel art strikes the perfect balance between appreciable craftmanship and the gestalt. A single pixel out of place, one too few or too many, ruins the illusion. There’s an unmuddied, economy of expression, the thankless result of the limitations of cartridge-based consoles.

At its core, play, and by extenion video games, is learning. Call it discovery or mastery but a good game introduces new ideas (teaches), leverages existing ones (reviews) and layers them to create unique challenges (tests). Teaching, at its core, is communicating. Verbosity is an academic sleeping pill. A game’s graphics are the player’s teacher and a good teacher is consistent, clear, and concise. Like good pixel art.

Super Mimeo Bros.

Mimeo (even the name) started as a Mario clone with a twist: instead of power-ups affecting the player, they affect the entire game world. A story and mythos quickly developed. The so-called Mimeoverse consists of two 16-bit demiverses sharing 32-bits between them. When the evil Kleptopus King, an 8-bit octopus with an inferiority complex, discovers a portal into Mimeo’s realm and begins to syphon off its bits, Mimeo is sucked in and downsampled to 2-bit. So begins Mimeo’s quest to restore balance to the demiverses.

Mimeo collects carts to upscale himself and the game world and enables switching between acquired resolutions to solve platforming puzzles. He will find guidence from nearest-neighbor and native rabbit Gaido. Collected bits translate into 1ups. Disposing of certain types of enemies leaves behind hoodies that grant Mimeo special abilities. The Quantum Glove puts Mimeo’s bits in a state of quantum supposition; enemies can’t hit him but they can’t dodge him either. “It’s so bad.”

8-bit Hits

In addition to creating the scenario, programming and designing all the graphics I’m also composing and producing all the music. The game uses a Nintendo NES 2A03 APU sound chip emulator (courtesy of Blargg) for authentic sounds that will keep pace with the game’s graphics. Here’s some sample mp3s of the foreboding Fortress:

• 2-bit bass
• 4-bit hi-hat
• 8-bit melody
• 16-bit counter melody

I’m using a combination of MilkyTracker with the nespack.s3m samples for composing, Garageband for arranging, and MML for producing the final NSFs used in the game.

Resolution

I’m aiming for a 2010 holiday season release. There is still much work to be done as every asset exists in 4 different resolutions (I said this project was ambitious) but the majority of core pieces are already in place.

You can follow along (and/or play catch up) with the process on Dribbble once it goes public. Over the course of development, I uploaded some short demo videos to Flickr and this slightly longer executive summary progress report to Vimeo:

via toucharcade.com

Back in October we highlighted an upcoming 2.5D sidescrolling puzzle platformer that drew inspiration from classics such as Metroid and MegaMan.

Original Teaser Video from October

The game was originally planned for submission in November, but after all the feedback he received in our forums, the developer decided to bring on more people to try to take the game to the next level. Two additional team members were added to work on artwork, sound and level design.

New screenshots are provided:

The latest developer update promises a well rounded and complete game:

We followed community feedback and as many suggested, we are taking the time to make a nice polished game. I can give you a hint at what to expect, +60 rooms (+30 unlockable with free updates), all filled with platforming action, physics-based puzzles, battles or all 3 Several ecosystems with nice artistic treatment and painted sceneries. Custom music tracks and sounds fxs. I know you will love the bosses and the story. The game is filled with hidden rooms, secrets and rewards. And as promised, full 60fps of pure gameplay response (we will even let you see the fps on screen if you want; its a geek thing)

The developer is working on a new gameplay trailer which should be revealed shortly along with the actual name of the game. We'll let you know as soon as we do. The developer is continuing to participate in the upcoming thread in our forums.

Effective Design for Multiple Screen Sizes

Posted by bryanrieger 1 year 3 days ago

See also...

• Accesskeys: Thinking about them in a QWERTY world
• Handset Market Share Data (why it matters)
• A Very Modern Mobile Switching Algorithm - Part II
• Mobile Web Design: Getting to the Point - Part II
• The Google Phone Cometh (so what)?

So you're a designer and have been tasked with the design of a mobile web site. Chances are, unless you're designing for only one device you're quickly going to be faced with a common problem experienced by designers who work with mobile devices; figuring out what screen size to actually design for.

For instance:

• The iPhone is 320 pixels wide by 480 pixels high.
• Many Nokia N-Series devices are 240 pixels wide by 320 pixels high.
• Newer devices often support a landscape mode where the width and height are spontaneously reversed.
• Older (yet still popular) Nokia devices have displays ranging from 176 by 208 pixels up to 352 by 416 pixels.
• Blackberry screen resolutions range anywhere from 160 x 160 pixels all the way up to 324 x 352 pixels.

This article is intended to help you develop effective design strategies to target a diverse range of mobile devices and screen sizes. To this end, we begin with an outline of two key issues you will encounter when designing for small screens—the diversity in screen and pixel size.

Expect and manage diversity

At this point you're probably asking yourself "...is it really necessary to design for all of these difference screen sizes?" or "...do I really need to create a separate design for each variant?" Depending on the business requirements of your project, it may be completely feasible to design only for one screen size—or in fact one device. However, if requirements dictate that the application (or web site) be usable by a majority of devices, you're going to have to find some way to deal with this diversity.

But wait, things may not be as bad as they first appear. When designing for the mobile web we can assume that pages will scroll up and down—as they do within desktop browsers. This somewhat removes the need to worry about the height of the screen, allowing us to primarily focus our efforts on dealing with the diversity found in device screen widths. Fortunately DeviceAtlas Explorer provides us a means to quickly visualize how the screen width property actually breaks down across the thousands of known devices.

As the graphs above indicate, the vast majority of devices share just three screen widths; 128, 240 and 176 pixels—with many of the remaining values; 120, 130, 160, 208 and 220 pixels—not diverging too far from these three core values. That leaves us with a few devices at both the high and low ends of the spectrum with a width of 96, 101, 320 and 320+ pixels. While devices with screen widths of less than 128 pixels may seem a small percentage of the whole, when combined (96, 120, 101 and 84 pixels) they add up to 469 devices! Over half the number of 240 pixel devices—or about 10% of all known devices!

It's probably also worth noting that at this time, less than 5% of devices have resolutions greater than 320 pixels wide. Expect this to change over the next few years as we're now seeing smaller screen resolutions (128, 176, etc) give way to the larger (240+); as illustrated in the following chart.

Considering screen size is important but there is one additional parameter to consider—the physical dimension of the screen.

The 'Problem With Pixels'

For years, designers have primarily been creating visuals for large desktop devices. Screen sizes averaging 1024 x 768 pixels have become the norm and although physical display sizes vary; the overall dimensions typically result in a pixel density of about 85 ppi (pixels-per-inch). Lately however, the display landscape has begun to change;

• 'Netbooks' such as the Asus Eee PC 900 have displays in the range of 9" diagonal with a resolutions around 1024 x 600 pixels giving them pixel densities of about 133 ppi.
• The Apple iPhone has a screen resolution of 320 x 480 pixels which when combined with its 3.6" diagonal display results in a pixel density of 160 ppi.
• The E60 from Nokia has a screen resolution of 416 x352 pixels packed into a tiny 2.2" diagonal display giving it a whopping pixel density of over 240 ppi!

When combined with the need to support many devices, this wide variance in pixel density introduces a new problem; the impact of pixel size on design.

The following illustration simulates the same 100 x 100 pixel image on devices with pixel densities of 72, 144 and 240 pixels-per-inch. Notice how type and fine details are lost as the image is rendered smaller and smaller.

Fortunately the race for "most pixels ever" has slowed and we're not seeing too many devices with pixel densities over 200 ppi. From a practical point of view, this means that it is unlikely you will have to support the very wide range of pixel densities illustrated above. It is however important keep in mind that not all pixels are created equal, and where possible:

• Determine the full range of pixel densities you will need to support.
• Review your designs on these devices to ensure critical detail is not lost.
• Design and define layout elements based on relative units such as ems and percentages. This will provide the team with a truer indication of the size and relationships between layout elements.

This 'problem with pixels' is sure to become more widely discussed in the coming years as handset vendors seek to build new levels of flexibility into their operating systems. In fact, Google's Android has already implemented a ">potentially interesting solution to the problem of pixels. The Android operating system is based on abstract 'dp' (density-independent pixel) units which are completely relative based on a 160 ppi screen density. This allows designers to specify fonts and a host of other interface elements in a relative manner with the knowledge that they will naturally adjust to suit the device.

With an understanding of the diversity in screen size and pixel density, we now outline strategies you can implement today to build scaleable mobile web sites.

Strategy 1: Define device groups

As we discovered earlier, while there may be thousands of device models, the diversity isn't as bad as it may have first appeared. In fact, it's entirely possible to group many devices with similar screen widths together and to end up with five distinct device screen width groupings:

1. tiny: 84, 96, 101, 128, 130, 132
2. small: 160, 176
3. medium: 208, 220, 240
4. large: 320, 360, 480+
5. desktop: 800+

These groupings are of course, entirely arbitrary and your project's requirements may dictate a different set entirely. For example; 320 pixels for the iphone and above, 240 pixels for more recent mobile browsers, and 128 pixels for older devices. In the end, defining device groupings really comes down to the goals and audience of the project. To this end, it's a good idea to visit DeviceAtlas on a regular basis in order to survey the device property landscape and reassess the relevance of your groupings.

You may also find that the development team will choose to create their own groupings based primarily on device capabilities. These are often described in a class based system where technical features (or limitations) are graded into categories that enable developers to only deliver a given functionality to devices that are capable of supporting it. For instance a 'Class A' device might be capable of supporting an advanced CSS spec, DOM manipulation and Javascript—while a 'Class C' device might only be capable of rendering basic XHTML-MP and rudimentary CSS. Be sure to consult regularly with the developers on a project to ensure that your assumptions and device groupings are compatible with theirs.

Strategy 2: Create a default reference design

After you've defined your device groups (and consulted with your developers) you're probably in a good position to select your reference device. This is the device that will serve as default during the design process and will ultimately lead to the creation of a reference design. Depending upon your business requirements you may wish to design reference versions for a medium (240px) screen size. This keeps the design simple enough to adapt to smaller screens, while allowing for a little more creative freedom on devices with larger displays. It's also not uncommon to choose more than one reference device and consequently, create more than one reference design (often based in some way on the device groupings described earlier.) This allows you to:

• progressively enhance the design for more advanced devices (ex: to take advantage of GPS, an accelerometer or CSS3 support),
• deal gracefully with devices that support differing models of manipulation (ex: touch devices), or
• adjust the design to compensate for severe limitations present on more restricted devices.

Strategy 3: Define rules for content and design adaptation

Once you've completed a reference design you should also provide specific direction for adaptation of this design to other screen sizes. Similar to the contents of a visual design document, these rules and guidelines should assist the development team in actually implementing the design in code. For example;

• The site logo should be replaced (or adapted) for each device grouping to ensure image clarity.
• Headers should stretch to 100% of the screen width using the supplied background image where possible.
• Content images should be no larger than 200px wide for the 'default grouping' (or 80% of the device's screen width).
• Content images should be automatically scaled and optimized to screen width if an alternate does not exit.
• List icons are not to be used on displays smaller than the 'default grouping' in order to make as much space available for the actual content.
• A dynamic style sheet is to be used in order to set many values on-the-fly for each device, and cached appropriately.

While not a formal recommendation, the above outlines common strategies to adapt and enhance design while keeping file sizes to a minimum. Always make design decisions based on the unique audience, goals (and challenges) of your project.

Strategy 4: Opt for web standards and a flexible layout

With the reference design and adaptation rules in place, the final strategy builds flexibility into the markup itself through the use of generic, standards based XHTML and CSS. In practice, this means creating markup that uses the tags and structures inherent in HTML (i.e. headers, paragraphs, lists and divs) to define the structure of your page. The immediate benefit—any browser that can read HTML will be able to display your content and will assign it an (albeit rudimentary) visual style. Given the vast number of mobile devices, this benefit cannot be underestimated as it ensures your content will be accessible to a large number of users without too much higgery-jiggery on the part of developers. You will then be in a great position to progressively enhance the design for different device groupings through the use of browser and/or device-specific CSS, graphics and scripting.

As described in the previous section, the content and design adaptations you choose to implement will vary depending on the project. Actual page width however, is one aspect that will typically not require formal adaptation. The issue of fixed versus fluid (or flexible) width designs has long been a topic for debate with web designers. The arguments tend to revolve around optimal text line lengths, wanting (or not wanting) the browser to fill the entire screen, and rendering issues related to large window width variances.

With the mobile web, these concerns don't weight in nearly as heavily. Line lengths are often too short regardless, there simply isn't enough screen real estate to have more than one useable browser window open at a time, and there isn't likely to be the extreme changes in width that might be possible with a desktop browser window. In fact, fluid designs lend themselves really well to mobile devices as they work beautifully with low-bandwidth design techniques that maximize the use of CSS and XHTML. These include:

• Not specifying a specific document width, thereby enabling the design to expand and contract naturally to fill the screen.
• Taking advantage of block elements which will also natively expand and contract.
• Using CSS background colours and tiled images to style layout and content elements.
• Specifying the size of layout elements using percentages so that they naturally expand and contract to fit page width.

Putting it all together

The following example from bbc.co.uk shows many of the design and adaptation strategies we have discussed in action. Let's first look at the XHTML markup.

<h1><img src="/mobile/images/hp-colours/tiles_greenblue.gif" width="75" height="34" alt="" border="0" /></h1>
  <!-- Editorial promo -->
  <h2>Featured</h2>
  <div id="topPromo"><img src="20081201180906.musicnews_mobile.jpg" width="170" height="96" alt="" border="0" />
  <p>Latest episode: La Roux, Kasabian and Jack Penate</p></div>
 
  <!-- News feed promo -->
  <h2>BBC News</h2>
  <div><img src="http://news.bbc.co.uk/media/images/45348000/jpg/_45348804_tank_getty226x260.jpg" width="66" height="49" alt="" border="0" />
  <p>Israel 'expands' Gaza offensive</p>
  </div>
 
  <!-- end News feed promo -->
 <div>
  <ul class="linkList">
  <li class="linkText">European gas supplies disrupted</li>
  <li class="linkText">Warnings issued amid Arctic chill</li>
  <li class="listMore">More top stories</li>
  </ul>
  </div>

The BBC markup is simple, standards compliant and relies on standard XHTML tags to define the structure of the content. This ensures that the basic content (consisting in this case of several headers, body copy, images and an unordered list) will be rendered—regardless of the device or browser. CSS is then used to style the content.

h1 { 
padding: 3px;
background: url(/mobile/images/hp-colours/banner-bak_greenblue.gif);
background-repeat: repeat-x;
background-color: #00594d;
color: white;          font-weight: bold;
font-size: small;
}
 
 
h2 {
color: #027063;
font-weight: normal;
font-size: medium;
padding: 2px;
background: url(/mobile/images/newimgs/h2-bak.gif);
background-repeat: repeat-x;
background-color: #ecedee;
border-bottom: 1px solid #c1c0c0;
}
 
 
h2 a:link, h2 a:visited {color: #027063;
font-weight: bold;
text-decoration: none;
}
 
 
h2 a:hover, h2 a:active {
color: #333333;
text-decoration: underline;
}
 
<;/pre>;
  <;pre id="line">;/* New promos */
#topPromo {
background-color: #000000;
}
 
 
#topPromo p {
color: white;
font-size: small;
border-top: 1px solid #757474;
padding: 2px;
}
 
 
#topPromo a:link, #topPromo a:visited {
color: white;
font-size: small;
display: block;
text-decoration: none;
}
 
 
#topPromo a:hover, #topPromo a:active {
color: #8ad3ca;
font-size: small;
display: block;
text-decoration: underline;
}
 
.linkList ul {
border-bottom: 1px solid #c1c0c0;
}
.linkList li {
padding: 2px;
padding-left: 19px;
margin: 2px;
}
.listTxt {
background: url(/mobile/images/newimgs/ico_txt_on-fff.gif);
background-repeat: no-repeat;
background-position: top left;
}

As you will note, the layout is entirely fluid. No set width is assigned to the page body, masthead, headers, lists or paragraphs. As seen in the example below, this results in a layout that performs much of the required adaptation on its own; simply scaling as needed to suit different screen widths.

The remaining styles and content are then specifically adapted server-side to suit the device or family of devices.

1. The logo is resized or replaced to suit the device screen width.
2. The masthead uses both a tiled and coloured background. Older devices like the Nokia 6680 which feature less sophisticated browsers are unable to render the tiled background but do display the background colour. Even simpler devices supporting only WAP 2.0 (XHTML-MP) may ignore both style properties altogether and simply display the logo. (Note that in the BBC's case, this causes a problem as the white logo is then displayed on white; rendering it somewhat illegible).
3. The BBC seems to have chosen to tailor the editorial to specific devices (or device groupings). While the iPhone includes a large 'Feature' item promoting music downloads, other devices jump striaght to the display of today's top 'BBC News'. This editorial decision may be due to the iPhone's flat data and strong podcast and media support but could also simply be due to its larger screen size. Were the 'Feature' displayed on a Nokia 6680 for example, it would take up most of the display forcing users to scroll to see today's top news stories. This decision is also counterbalanced by the reformatting of content further down. While all three news stories are displayed on the iPhone, only one includes a photograph. This once again enables all the top news content to be seen without scrolling.
4. Images are scaled or replaced to suit the width of the display.
5. On larger devices, icons are associated with each list item. While not visible in the example below, this stylistic element is removed on smaller devices ensuring a comfortable line length for the accompanying list copy.

A balanced approach

The BBC web site is an ideal example as it shows how simple it can be to combine clean markup with well conceived styles and strategic editorial decisions to achieve a great experience on a wide range of devices. Ultimately, your design, adaptation and editorial choices will be based on many factors including your budget, target audience and the functionality of the mobile web site you are designing. In the end, it's all about striking a balance between the creation of a well optimized, fast-loading site and the delivery of great, targeted content to your users.

For an in-depth look at the what makes a truly great mobile application and the design of mobile web sites from a user interface, functionality and usability point of view; be sure to read Mobile App Design: Getting to the Point Part I and Part II.

AT&T Rolls Out Cheaper Unlimited Plans, iPhone Monthly Rate Drops $30

Friday January 15, 2010 05:21 PM EST; Category: iPhone
Written by Eric Slivka

Responding to price cuts from Verizon, AT&T today rolled out new unlimited plans for all devices on its network, including the iPhone. Under the new plans taking effect on Monday, iPhone customers can sign up for unlimited voice and data for $99.99 per month, although texting packages remain separate for an additional fee. The unlimited voice and data plan represents a $30 discount from the previous unlimited plan for the iPhone.

All smartphone customers, including iPhone customers, may now buy unlimited voice and data for $99.99. For smartphone customers with Family Talk plans (prices assume 2 smartphones), unlimited voice and data is now available for $179.99. Texting plans remain unchanged at $20 for unlimited plans for individuals, $30 for Family Talk Plans.

Existing customers will be permitted to change to the new plans as of Monday via AT&T's website, with no monetary penalty or extension to contract terms. It is unclear at this time whether there will be any adjustment to AT&T's non-unlimited plans to reposition its pricing tiers in relation to the new, lower unlimited price.

Rating (17 Positives; 6 Negatives)
[ 10 comments ]

NOVA Launches December 17th, New Video

posted December 15th, 2009 2:28 PM EST by arn in Upcoming Games, iPhone games, iPod touch games

Gameloft's NOVA is probably the most widely anticipated game at the moment. After first being announced in September, excitement has been high for this Halo-like first person shooter.

Gameloft released an impressive new trailer today and finally gave us a release date.

NOVA will launch on December 17th. In related news, Gameloft also released a new GT Racing trailer showing even more in-game footage. See our hands on preview for other early details.

'Low Grav Racer 2': A Step Closer to Wipeout

posted December 14th, 2009 4:27 PM EST by Blake Patterson in $2.99, Racing, Reviews, iPhone games, iPod touch games

Just over a year ago I reviewed CobraMobile's futuristic racing game Low Grav Racer [App Store]. Way back when, it was a visually impressive game and indeed the closest thing to Wipeout in the App Store. (And the degree to which any given low gravity, futuristic  racer approximates Wipeout, the king of futuristic racers, is really the critical metric in determining the game's worth, so high did Psygnosis set the bar of that genre, as every gamer other than die-hard F-Zero devotees are aware.) Though an enjoyable game and, as I indicated, Wipeout-like, Low Grav Racer was, in fact, no Wipeout. Surely driven by the urge to close the gap, CobraMobile has just released Low Grav Racer 2 [App Store] for the iPhone and iPod touch. So how does it fare?

Low Grav Racer 2 puts you in control of any of six futuristic racing craft (three of which must be unlocked) in a race to the finish line across 18 different planet and space system-based tracks. There are two race modes: Single Play and Time Trial. The former is a competition to complete each track in first place against five AI competitors, while the latter is a solo challenge to get from start to finish in the least time possible. As in Wipeout, leading the pack involves more than just speed and savvy handling; it involves weaponry. Scattered about each track are power-ups that enable shields, mines, missiles of several types, speed boosts, and various other items of destruction that help to slow down the competition — and, likewise, help the competition put a little slow on you.

So far the description of LGR2 sounds a lot like that of the original Low Grav Racer. LGR2 does bring a number of enhancements that improve the overall gameplay as compared to the original. The most notable difference is the significantly enhanced draw distance. The original title used a heavy fog effect to mask pop-in, while LGR2 more fully renders distant track elements and the floating, futuristic items of scenery, lending a rather more realistic feel to the overall situation. As well, LGR2 delivers a more intense feel to the race thanks to apparently faster action and tighter track design. Both versions feature very smooth animation with a solid framerate, but there's more going on in this latest release. As well, Plus+ network integration, tracking awards and leaderboards, adds to the game's play incentive.

Like the original, LGR2 features solid accelerometer steering control with a tap to brake and fire weapons. Sadly, like the original, LGR2 lacks left and right airbrakes, an element of Wipeout that allows for superb ship control. I was disappointed to see this feature still not realized in the sequel release. Another criticism I might voice is the overly spacious feel of the tracks. While it is less of an issue in LGR2 as compared to the original, I prefer tighter tracks that demand real control excellence. That's not to say that in this release you don't spend plenty of time scraping along the edge of the tracks thanks to their various twists and turns or slamming into rock formations that protrude into some of the courses, but tighter tracks make for a more breakneck race session. Also, I would prefer that your ship take damage during said collisions, but that is not the case with either LGR release.

The developer's gameplay video illustrates the racing action.

So, is Low Grav Racer 2 a match for Wipeout? Not quite. It gets us closer than the first release, certainly, and is a quality racer that's both challenging and fun. Those who enjoyed the first outing will likely find LGR2 to be worth the price of admission, and those new to the series who like what they're hearing should bypass the original and go straight for this sequel. As more a fan of futuristic racers than the rubber and asphalt variety, I consider Low Grav Racer 2 to be one of the stronger racing games in the App Store.

App Store Link: Low Grav Racer 2, $2.99