Daisy Chase gameplay
Moseycode registration
Scanning a Moseycode to get new levels
It’s been an extremely busy few weeks and I’m now looking forward to having a little more time to focus on Android development again. One thing I did achieve this week was to put live a very early version of a game I’ve been developing called Daisy Chase. It’s a “simple” game in which you have to capture flowers by linking them together. I say “simple” instead of just simple because I’m again humbled by how I can misjudge what users will really can understand simply. Nevertheless, I’m quite pleased, the game appears to work (no bug reports yet) and some users report really enjoying it. I would have liked to have entered it into the ADC2, but I had no time (and the competition in the game categories looks especially strong).
I’m really excited about two elements of this new Android application. The first is that it will be the first application that makes use of the Moseycode publishing API to allow users to publish, own and share their own levels. One of the screenshots above gives a preview of the user registration page (not yet incorporated into the application).
The second thing is that, as a big fan of the Intent system used in Android, I’m looking forward to the integration that game will have with Daisy Garden. For example, By achieving particular goals on a level, you will win one of the flowers that appears in the level and this will be added to your garden. In the full version of the game, levels will be collected into gardens and completing all of the levels in a garden will add that garden to the collection of gardens you can grow flowers in.
It’s all part a minor (but time consuming!) experiment in how games, and not just regular applications, can be broken down into separate units that have individual value. It’s a remarkably involved task to do effectively.
The alpha version of Daisy Chase is available from the Android Market.
With a number of Android applications laying incomplete in my digital atelier, I felt a pang when Dan Morrill announced that the Android Developer Challenge 2 was open for submissions on Twitter. I’d had no intention of entering the competition until I read that tweet and felt personally challenged. Rashly, I decided that I could get Moseycode integrated and the rest of the application adapted for ADC2 in a handful of long evenings.
It’s too early to say whether I’m going to make it yet, but I’m glad I’m shooting for it. This is one of the products of my rapid labour: the ability to publish flowers from your garden as pictures that you can share. Anyone else with the application can import the flower directly from the in-built Gallery application or by scanning the picture with their phone camera.
I really like the idea of this sort of sharing - where the artefact is both appreciable by people and machine readable. I don’t know how it’s going to pan out yet, but you can expect more of this approach from my next applications (and not necessarily via moseycodes either).
I’ve been holding back on releasing Daisy Garden because I really wanted users to have the ability to share their flowers from the first release. Now I’m wondering whether I can introduce this feature in a sprint and get the application ready for the close of the ADC 2.
I’ve just published an updated design for the Moseycode website. It’s not going to win any Webby’s but it’s an incremental improvement.
With these cosmetic changes in place, I’ll be free to concentrate on filling the site with information and documentation related to Moseycode.
To get this off the ground, I’ve integrated my Moseycode related blog posts (like this one) into the site. But realistically, the site will remain just a shell until I start publishing the application and its source code.
Under the hood, there are a couple of new features:
A media upload facility is now available. Using this it will be possible to customize the appearance of barcodes you publish at the site. But it’s not possible to actually do this at the moment so I wouldn’t bother.
A new API is in place that allows third-party applications to authenticate users and list/publish moseycodes on their behalf. It’s a compact little HTTP based API that accomodates a simple & efficient implementation. When the Moseycode source code is released it will include a helper package for interacting with the API (which is definitely not stable at the moment).
It also features a small CAPTCHA library I wrote because I couldn’t use (or had good reason not to use) any of the available grails CAPTCHA plugins. It’s a bit hard to read at the moment - sorry about that. Naturally, I’ve managed to introduce a couple of bugs too so those might take a couple of days to iron out.
Moseycode logo concept.
Not directly related to yesterday’s algorithmic challenge, just some speculative barcode design work. Colours courtesy of Mary Ann.
Moseycode is an augmented reality barcode system that I’ve been developing for the Android platform. As the project’s profile slowly grows, I’ve had a number of people ask me about the suitability of Android for similar projects. I’ve decided to put my comments, such as they are - limited by my own narrow experience - into a post so that I can refer future enquiries here.
I started developing Moseycode when the Android SDK first became available - before any Android powered phones were available - so much of the early development of Moseycode was done using a PC, a webcam and the JMF framework. None of the image processing I’ve been focusing on has required high resolution capture, but webcams are really very problematic - especially since they usually lack any focus control. The upside is that if you get your algorithms working reliably with webcam captured footage, you should be pleasantly surprised by the results from anything else!
Though I’m a huge fan of the Android platform, I think it has some drawbacks at present for this sort of development:
Generally I would rate the image capture quality of the G1 as fairly poor. This is probably hardware related but I’d speculate that some of it may be due to underdeveloped drivers. I can’t comment on the image quality from other phones. The auto focus though is a major boon to barcode capture.
I like the SDK (I’m an experienced Java developer) but real-time image processing won’t fly with the current Dalvik interpreter; the C/C++ support in the form of the NDK is very focused on compatibility and not features (which is definitely the right call) so consequentially the available libraries are quite minimal and this might cause difficulties porting over existing image processing libraries (though I’m not sure - I haven’t had to try).
The camera APIs within the Android framework are weak. I always feel I have to qualify this by saying that (1) this is simply my opinion, check out them out for yourself and form your own opinion, and (2) there are many reasons that poor APIs arise, most of which are not the responsibility of the engineers who craft them. That said, there are some serious structural problems in the APIs that thwart attempts to write portable and performant applications. Many of the problems are documented in the public issue tracker. My bête noire is issue 2794. I’ve got as far as posting an outline proposal for how things could be improved but I’m unlikely to find the time to attempt an implementation until the first release of Moseycode is out of the way.
There is no effective API available for parsing and and rendering 3D object models. I don’t necessarily expect one to be provided within the standard framework, it’s simply unfortunate that, at this time, the platform is not sufficiently mature that any such libraries are available. Perhaps if/when OpenGL ES is directly accessible from native code it will be possible to port an established C library.
All those niggles notwithstanding, it’s exciting being able to capture and process live image data on a mobile phone, something that’s so central to people’s lives. Combined with Android’s powerful abstractions that support collaborative applications it’s really exciting.
I’ll end by saying that I’m currently working towards releasing Moseycode as an open-source platform that developers will be able to re-use at a number of levels. Android might be a more inviting target for augmented reality applications when that is available since it will provide a jumping-off point for developers to build their own applications.
The new icon’s pretty rough - I’m not familiar with blender - but it doesn’t matter at icon resolutions.
Woke up not tired for the first time in a month - that evil flu must be losing its grip. So I had the energy to actually an create an icon for Moseycode, quite how the application has survived development so long without one is a mystery.
How did Moseycode’s threading get so complicated? Inattention?
