Nothing, however simple, goes without saying

My girlfriend borrowed a couple of cables from her office today, so I finally managed to wire the E61 to my netbook. As a first best, I hoped, Eclipse Pulsar would recognize my device. As a second best, I was thinking using the new and shiny Ovi suite to install my test app. To the average noob, Pulsar is the usual rhizomy mess of menus and panels, so after toying with the spider awhile I decided to try my luck online, indeed landing a nice Wiki page Entitled “How to install Java ME application in mobile phone“. Among numerous equally-unattractive-to-a-developer ways to install java apps on a nokia phone, I quote:

“If the device has a serial cable port and connectivity software for a PC, the MIDlet can be installed on the device over a serial cable”

Which I edited to:

To install the MIDlet, double-click on either the *.jar or *.jad file and follow on-screen instructions. On a PC, if jar/jad files are not associated with PC suite or Ovi suite by default, you can right click and select “open with” then choose “Ovi suite” or “PC suite” as applicable.

I always thought that PC suite associating jar files to itself in this way is somehow of a pre-emptive way to suggest that java doesn’t have a life beyond Nokia phones. Now I will modify my file associations, as I happen to have tens of thousands of lines of code on my PC that are nothing MIDlet.

I don’t care whether this goes without saying or not. I wasted another hour on this. I’m in a bad mood.

If it doesn’t work, downgrade CLDC and/or MIDP

In Pulsar, open the M folder labeled Application Descriptor. Then select create package to actually get a deployable jar/jad file. Since my device is 5 years old, I had a friendly ‘can’t run application’ or such message when I tried installing. By default, Pulsar is configuring to MIDP 2.1 (at the time of writing this, using the latest SDK). Until I find a reason not to, I’ll just downgrade CLDC and MIDP (in the ‘M panel’) to the oldest version that I can run something against.

Pingoo goes live

After I downgraded MIDP to 2.0, (note the advice on Nokia wiki if it doesn’t work for you), the Pingoo displayed at a decent FPS on my E61. I really need to come up with something chunkier, right?

So I used fractal subdivision in Blender to bump the poly count to ~10,000. This slows down the M3G exporter to a crawl because it spits out console output for every face. The M3G file inflated from 21kb to 565kb. FPS dropped to 2-3 frames per second, flat shaded, with 2 point lights enabled (no textures).

There are many ways to waste a decent Sunday. Today I’ve decided to figure how to make and use ad-hoc distributions.

Overview

If your testers are local enough, borrowing their devices overnight and loading your app on their phone yourself is a good option. If your testers aren’t local, you won’t be there to help them, and they won’t be using XCode. Instead, we create a special provisioning profile for your testers’ devices and email this along with a copy of our app built against that profile.

Creating an ad-hoc distro for testers is pretty much the same as creating a developer build. Here are the differences:

• You need a distribution provisioning profile, NOT a developer provisioning profile.
• Like devs, testers need to install the provisioning profile onto their device before the device can run. This step is not entirely intuitive (well… release builds don’t require this, right?), however many articles explaining how to make ad-hoc distros skip on this.
• Like devs, testers need to install a build matching the provisioning profile the app was built with.
• Unlike devs, testers use iTunes, not XCode. Steps to install provisioning profiles and apps from iTunes aren’t quite the same on OS-X and windows (see ‘installation’ below).

Creating a provisioning profile for testing.

I am assuming you have already completed the steps required to make a build work on your own device(s) and are moderately familiar with the provisioning portal.

1. First off, you need your beta testers to provide their device IDs. A simple way to collect device IDs is to get your testers to download one of the many free iPhone apps that ease this process, such as UDID+. Simply put, the tester runs the app, then they press ‘send email’ and their device ID appears in the body of the email they’re sending you.
2. Log into the iphone dev connection website and navigate to the provisioning portal.
3. Go the ‘Devices‘ tab and add your tester(s) devices.
4. You need to create a provisioning profile for ad-hoc distribution. This profile will include the devices that the test build can run with.
   (a) select the ‘provisioning’ tab.
   (b) select the ‘Distribution’ sub-tab and select ‘new’ to make a new profile.
   (c) In ‘distribution method’ check ‘Ad hoc’. Choose a name (e.g “MyApp Beta”) and pick your app ID from the list.
   (d) check the box(es) to include your tester(s) device(s) and press submit.
5. After a couple of minutes, refresh the page (profiles aren’t immediately made available for download). Then download the new provisioning profile and drop it in a folder named ‘beta’. Later you need to email the provisioning profile to your testers so they can add it to iTunes.
6. Don’t forget to add the new provisioning profile to XCode as well.

Creating a test build

1. In XCode, switch to a device build. Debug or Release is OK. If you choose debug, it makes it easier to interpret crash logs later.
2. In the XCode project browser, right click on Targets > YourGameName and select ‘get info’.
3. Go to the build tab and have a look at the ‘Code signing’ section. If you didn’t forget to add the new provisioning profile to xcode, you can select it in the drop down menu near ‘Code Signing Identity’ and ‘Any iPhone OS Device’. (I just set both fields to the testing profile, but I think the idea is that we can associate profiles on a per device type basis)
4. Select Build & and Archive in the build menu.
5. You can find archived apps (and profiles previously added to XCode) in the XCode organizer. To find your build, right click/shift-click the date associated with the archived version you want and select ‘reveal in finder’.

Sending your app to testers – installing an ad-hoc distribution.

Testers need the following:

1. Copy of the provisioning profile (the *.mobileprovision file we have created)
2. Your ‘archived app’. I enclose this in quotes because although this is an ‘archive’ on a windows machine it would really look just like a folder with the *.app extension,
3. A computer (Mac or PC OK)
4. iTunes should be installed on their computer.

Installation – PC

1. Open iTunes
2. Go to ‘add file to library’ and add the *.mobileprovision file. Alternatively, drag and drop this file into the iTunes window (in iTunes 10, seems to work better if we drag into LIBRARY section on the top left).
3. Drag and drop the *.app folder into iTunes. We can’t use ‘add file to library’ because windows doesn’t recognize *.app folders as ‘files’.
4. Sync the device (you may need to include the app into the list of apps added to this device first)

IMPORTANT – If the app is added first, the above may not work until iTunes is restarted.

Installation – OSX

1. Open iTunes
2. Drag and drop the *.mobileprovision file onto the iTunes icon (or use ‘add file to library’)
3. Drag and drop the *.app file onto the iTunes icons (or use ‘add file to library’)
4. Sync the device (you may need to include the app into the list of apps added to this device first)

IMPORTANT – If the app is added first, the above may not work until iTunes is restarted.

References

I’ve been poking around to get this information; then I tested everything step by step until I got it to work.
You could check the original document about ad-hoc distributions for testers (from the Apple site).

After…

• A super-long week-end (just 3 days really)
• Adding an app icon (57×57 png, add to your project, then list in your something-Info.plist file)
• Adding help, pause, a splash screen and a loading screen
• …

I got a few friends to try my game. I was actually deluding myself into believing this thing is playable. Well just about. Most of my friends are non players and non iPhone users. Realtime 3D or whatever I put into it to make my game exciting, attractive, and worth giving a go, means nothing to them – gotta remember they’ve just seen Avatar in an IMax cinema, right?

Usability

After Doodle Jump’s super-massive international success, I like to kid myself into believing that every iPhone gamer can tilt their phone (also a good way to keep your screen clean). Before I get back to my fairy world, maybe I should list some of the many usability issues that seem to plague my game.

1. Tilt. My tilt navigation isn’t super sensitive, and it’s pretty easy to stop moving also. Since there had to be a way to go pick the phone while stirring your veggies, in other words get your both hands free, I only use touch for action buttons and pausing the game.
   I love it, and would contend this is ideal for an adventure game with light action, but I’m really worried after seeing how quickly this gets the non-initiated frustrated with my baby app. I’m currently considering drawing a pad on the screen. Now that’s gonna bore me to bits.
   It’s not just because I don’t want to get into GL picking this round. Many games seem to provide touch and a joypad emulator, and some testers seem to favor the latter.
2. Not seeing their character. That’s the downside of having a fairly complex game stage and automating camera management. Making sure the camera is always well placed isn’t so easy, and i’m still working on it.
3. Getting blocked. I’ve more or less given up on having the PC fall down cliffs in my game. Everywhere is cliffy and it’s not meant to be Super Monkey Ball. My trial users like to run into walls, and feel stuck.
4. Getting kinda stuck. Because my terrain is a little complex, I already put a lot of work into avoiding getting the PC completely stuck between rocks or other things. I half believe having easier controls is more than half of the problem – I see my mock players getting stuck in places they really didn’t intend to go… but…
5. Talkback management. When my game pauses, I display a little on-screen explanation showing how to play the game. This starts with the Avatar talking to you and it’s really cute. Problem is, when touching the screen again, the talkback doesn’t disappear right away. So I had a friend pressing again, which pauses the game again, doesn’t make the talkback disappear (that one’s got a timer) either. Then they press again. And again. And again…
6. Where are the buttons. I don’t really want buttons to cover half of my 3D view. I made them reasonably sized (fingertip sized?) and translucent. Maybe a little too translucent…

The one true player that really enjoyed my game so far is an 18 months old. Pity demographic transitions and the baby crash.

Gameplay

Right. All that stuff makes me feel a little sad after the groove of feeling ready to show off stuff. Good news is, my next target is putting together preview pics.