It’s a rare occasion, but it’s the morning indeed and I happen to drink my coffee, so I’m 100% true to my chosen series name.

• Good introductory article on Chipmunk physics engine. Our hit title Finger Physics was actually written with Chipmunk and even though we switched to Box2D later for our next phyiscs-based games (Finger Physics: Thumb Wars and the upcoming Feed Al), we still have a good feelings about the Chipmunk.
• Two articles by Shawn Hargreaves about data compression for 3D graphics – Compressed GPU Data Formats and Compressed Vertex Data. Examples are written in C# and will be immediately useful for those of us who writes for Windows Phone 7, but general principles are also applicable to OpenGL ES developers.
• For those of you, who is subscribed to the Game Developer Magazine, there is an article by Noel Llopis reviewing gDEBugger for an iPhone. It’s pretty expensive about $1000 per seat, but if you’re doing something 3D intensive on the iPhone I think it’s a very valuable tool.

• Game Center via OpenFeint – in the last year or so, most of the indie game developers used OpenFeint as their leaderboards and achievements system of choice, but now with the introduction of the Game Center, which is less sophisticated feature-wise, but powered by Apple’s reality distortion field – developers, unfortunately, have more choices to make. OpenFeint just recently announced transparent support for Game Center, so in theory one can get best of both worlds and this article describes such experience. It’s fairly light weight – both integration process and the article – but still worth reading.
• Ruby eBooks – again, I consider Ruby a must have scripting and server-side technology for mobile developers, so this article mentions couple of free Ruby ebooks that you may want to add to your virtual bookshelf.

Does it make sense to develop for an iPad

Does it make sense to develop separate iPad-specific version of the game? This is a tough question and if I was able to give a definite answer to it, then I would probably be driving my Tesla Roadster to my Bora-Bora vacation house already.  My gut feeling that initial sales of iPads will be big enough, but not overwhelming and having an iPad version for most of the games will not drive a significant revenue increase over normal iPhone revenue. However Apple is pretty open about the fact that they will pay extra attention to the presence of the iPad-specific version while selecting which apps they are going to promote and Apple’s promotion so far is the most efficient marketing tool one can use.

From competition perspective, we should probably expect that all major publishers and all successful indies will have iPad-specific versions of their games on the launch date or close to it, so I doubt that presence of the iPad version will give a competitive advantage. Using a Pareto principle, we can say that 20% of the apps in the AppStore drive 80% sales (though in reality it’s more like 2% drive 80% of sales). Most likely those 20% (or 2%) will have an iPad-specific builds, so there’s not too many opportunities to capture market share from big players, but there may be a temporary opportunity to capture some market from existing small-to-medium size players who will be slow on the iPad adoption. Just to give an example, right now there are probably few hundreds of solitaire games on the iPhone. Most of them are developed by small companies or even individuals and besides MobilityWare’s Solitaire there aren’t other established leaders in that genre, it’s easy to expect that majority of small solitaire vendors will be slow on adoption (due to the increased costs) and therefore there’s a temporary opportunity to get into a top 3 solitaire games on the iPad, if your solitaire game is released pretty close to the launch. However, that’s probably a fairly short window of opportunity and its effectiveness is largely dependant on Apple’s strategy, if they will provide some sort of filtering mechanism in the AppStore to show only apps that explicitly support iPad and therefore will allow you to stand out.

Key Differences and Complications

• Screen size: Difference in screen size is a biggest obstacle. iPhone is 320×480, iPad is 1024×768, this is 5x difference in size and different aspect ratio. So unless your interface is very scalable by it’s nature (browser or maps apps are good examples), most likely you have to completely re-design UI and game presentaion. It’s especially hard for 2D games, so doing games in 3D will have certain advantage in terms of porting. In general, supporting both iPhone and iPad will require producing many (if not all) graphical assets in 2 different screen resolutions. If the game is planned as multi-platform it may make sense to use Android’s WVGA screen (800×480) as a baseline, since it’s somewhere in between iPhone and iPad and for some games it will be possible to scale down for iPhone and scale up for iPad from baseline WVGA with less expenses than doing completely separate iPhone and iPad art packs.
• Speed: Performance is already acting like a pretty big fragmentation factor on the iPhone since performance difference of iPhone 2G and iPhone 3GS is quite drastic. I’ve seen games that are perfectly playable on 3G and 3GS, but sluggish on 2G and it’s not very wise since iPhone 2G is still more than 20% of the market. Now with the iPad the difference between slowest and fastest device will be much more drastic and most likely games should either have different feature set or dynamically switch certain CPU-intensive features like FX effects, LOD (level of detail) or complexity of AI depending on the device.
• Controls: While both devices will have similar controls schemes, there are still few important differences.
  • Physical size of the screen: important difference between iPhone’s 3.5” screen and iPad’s 9.7” screen is that most of the people are able to use both of their thumbs to reach any part of the screen on the iPhone, i.e. you can use the entire surface of the screen for active elements. On the iPad though, average person will only be able to use their thumbs to touch relatively small area around thumbs while holding the device in both hands or have to switch to the holding device in one hand and using index finger for all inputs (which has its own disadvantages described below). That means that controls should be grouped around the part of the screen adjacent to your thumbs. So instead of using 100% of the screen as an input, on the iPad only fraction of the screen can be used for active elements.
  • Weight and physical size of the device: iPhone is small and light enough, so users are comfortable with both holding it one-handed and using index finger of the other hand for controls and rotating/leaning the device for accelerometer input. While iPad is pretty light and not awfully big, it will still change the user’s behaviour. Holding 1.5 pounds device by one hand for fairly long period of time is not comfortable for most of the users, so people will either have to hold it in both hands and therefore control the game mostly with thumbs and not by the index finger or will have to put it somewhere (desk, lap, coffee table) which most of the time less comfortable and screws the viewing angle. Same factor applies to accelerometer input, it will be less precise and more physically straining to move 1.5 pounds in the air compared to an iPhone, plus the physical size of the device can make it less comfortable for player and surrounding people in space-constrained environments (think about playing DoodleJump on the iPad while seating in the middle-seat of the economy class). Therefore I believe that most of the games will restrain from using accelerometer as main input device.
• Application size: Most of the developers knew that keeping size of their games below 10 Mb was important to increase sales. Its started to become less important lately as more and more users become more familiar with the way AppStore works, plus just few days ago Apple increased limit from 10Mb to 20Mb. However with an introduction of universal binaries which contain both iPhone and iPad versions combined, this problem will become important again. Due to 5x increase in screen size and higher user expectations in terms of quality and diversity of graphics for iPad games, it’s likely to expect that average size of graphical assets for iPad game will be close to 20Mb or even more, so having universal binary and maintaining its size under 20Mb can become a substantially difficult problem. It’s fairly likely that Apple and/or AT&T will increase or remove a limit fairly soon, otherwise for many games it will be advisable to keep a constant attention to the combined size of assets

Morning coffee is a collection of interesting links I happened to discover today

• One year after the acquisition: was it all worth it? – blog post of the CEO of the FutureTap, German iPhone developer, who purchased a popular Where To application from Tap Tap Tap and now reflects their sales stats.
• Play iPhone Movies in Portrait Mode with MPMoviePlayerController using Public API’s – an article about clever hack for playing video in portrait mode without relying on private API, which is a big no-no nowdays.
• AdMob posted an update on their stats that shows a tremendous increase (2.5x times in last 3 months) in ad display requests coming from the Android-based devices.

• NimbleBit posted their sales numbers for few of their games.  While it looks like they have only one “real” hit, which brought them almost $300K with the rest of their games bringing way less, I am still amazed that many of their games took them very small amount of time to develop. Usually it’s about 1 man-month with extreme case of less than a week. Very inspiring!
• Google released their new project – Google Collections Library, which includes a lot of innovations in Java collection libraries. It’s not strictly mobile, but I believe that any Java programmer should look into it, since collections are foundation of pretty much any application.