I suppose it is a natural progression, particularly in such a young market. iOS development has only been around for a few years, and there’s still that buzz of excitement when anyone speaks about app development. It’s still in its cool phase, and it draws a many and varied talent base, a considerable number of whom this is one of their first main development in-roads. It has taken me the better part of 15 years to get where I am (wherever that may be), so it comes as no surprise that many of them can count the number of successfully completed projects on one hand.

There’s ability out there, there’s no denying that. But the problem lies not in the skill set, but in the timing. Apps are big business right now, and many big brands are pushing hard on the app wheel. The trouble is they simply can’t get enough apps developed quickly enough, there simply isn’t the talent to cover the work load, not by a long stretch. In fact, I’d go so far as to say that much of the world’s senior development experience is still doing what it has done for years, manning development teams, creating quality, best-practice code and locking it up in big business. After all, if they’re happy, and they’re getting paid, why should they alter the status quo? So the iOS app development market has no choice but to take on less experienced developers simply to keep up with the workload, some of which can work out very well for all concerned, but some of which can leave a legacy of pain for years to come.

Pragmatic Programmer has given me a chance to remind myself just how difficult this job is, how easy it is to make mistakes, head in wrong directions, and generally cause headaches for all involved. It is a fantastically educational tome, and I think if I were to employ any new recruits right now, I’d be looking for them to have read it, and be conversant with its key principles; orthogonality, Don’t Repeat Yourself, coding defensively, all seem second nature to those who have coded through the last decade, but the amount of iOS code I’m coming across that flies in the face of even these most basic of principles is simply staggering. The worst thing about this situation is that clients need to get experienced developers on such code just to keep it working. It’s crazy to think that some of the best talent in the industry are spending huge chunks of their time fixing this bad code instead of creating new apps.

Reminding myself of the contents of this books means I can at least do my part to pass on some of what it means to write good maintainable code for clients. And I guess we should always try to take the opportunity to pass on what we’ve learnt. Sure some of us might lose some work as the bad code that would otherwise need maintaining slowly disappears, but just thinking of all the great apps we could all be writing instead would seem like a trade worth making.

You find a great client, working with a great customer, commissioned to create a great product.; in the development world, the perfect triumvirate.

Journey to the Exoplanets on Apple’s iPad had the potential to be good right from the off. Along with my client Brandwidth, and their customer, Scientific American, this perfect triumvirate served to create an unusual level of expectation that, despite going unvoiced, managed to hover over our heads from the first line of code through to the final submission process.

It wasn’t perfection, I’m not even sure such a situation is possible, but it’s about as close as any project is going to get. The artwork was done with passion and intensity. The development was pushed hard by a design that in many respects went way outside the conventional app thinking. But perhaps most importantly, everyone involved, the client, the customers, the team, all saw the potential, and worked hard to realise it. People basically gave a damn, and for that to happen right across the board is rare. To get a chance to be working on such projects amongst such people is rarer still.

So it was of course a pleasure to work on. The design goals were met, and in many places exceeded. We all set out to make a great app that would blow people’s minds, and I think we did that in spades. Three months of ups and downs, trials, errors, backward steps and breakthroughs, all with a finished product to show for it.

I’d always expected there to be euphoria on releasing a product, particularly one that I’d built myself from scratch. In this case it’s actually more sadness than anything, good things have to come to an end after all. Possibly the hardest thing to reconcile is that, from now on, I’m going to have such high expectations with everything I touch. Is it really possible to hit a home run twice in succession?

As a final note, a quick thank you to the guys at Brandwidth and Scientific American. These last few months really have been an absolute pleasure, and I look forward to breaking expectations together again in the future. And of course a big shout out to Caleb Sharf ; having the assistance of the Director of Columbia University’s Astrobilogy Center really did push the Planet Builder above and beyond.

Update: some great reviews are coming through for the app, so feel free to check out the article on fastcodesign.com, as well as a great review by author Greg Bear on TOR.com.

I love the possibilities, the opportunities, for creativity, for storytelling, for stretching the imagination in directions it could never go in real life. But I hate how the games industry has transformed over the last twenty-five years.

For me, gaming kicked off with miners running through caverns, dodging flying telephones, saws coming up through the floorboards, ants dropping boulders whilst avoiding butterflies, spraycans spraying pests on impossibly tall plants, men with jetpacs constructing rockets whilst killing aliens, the sheer randomness of the backroom creations was incredible.

But it didn’t take long for the businessmen to catch on, after all this was a nascent industry replete with investment opportunities and subsequent rewards. Art and creativity rapidly became business and cash cows. Out of these times grew Sega, EA, and many many more. The industry was born, and along with it both the marketing plan and the sequel.

Reading through a prominent games magazine at the weekend was enough to make my old Kempston joystick weep in its land fill site. It has been a topic of fierce debate over the years, about business both saving and ruining games, about the pros and cons of market-led development, but when you go through the list of upcoming releases, and every single game, not some, not most, but every single game is either a football game, a first-person shooter, or a sequel of a football game or first-person shooter, you can’t help but wonder where it all went wrong.

Thankfully the dearth of the smartphone has pulled us into a slightly different lane of the gaming motorway in the last couple of years, and people are having an opportunity to experience at least some of the potential inherent in last centuries madcap creations. The oftentimes simple creativity found in games like Doodlejump, Angry Birds and Plants vs Zombies at least have pretensions for freshness, and the use of the camera, gyroscope and GPS units have the potential to take things on a step again. But that is by no means certain.

Perhaps this is the start of a new era, an opportunity for “real new” and not just “new clothing”. I hope so. That magazine was more depressing than you can imagine, and nothing would give me more pleasure than to see over the next decade the games industry come full circle, back to its creative roots. With my impressions of the games industry edging towards the hate camp right now, I would give plenty for it to take a swing back to love again.

Update: And this is exactly what I meant. THQ posts 2011 losses, and what is the first headline we read? “THQ sales slump for FY2011, looking to successful sequels in 2012“. Something goes a little sideways, and straight away they’re looking to sequels to recover. Hardly a winning strategy for the long-haul, nor one to excite any potential customers.

Update 2: Oh and for the record, rehashing classic games on a new platform, but doing it so badly that no-one would go near them with a stick, is just as bad. C’mon people, you’re better than this!

What’s really crazy is there was still time to eat, drink and sleep in amongst everything else going on. I’m kinda glad really.

Many contracts start as a trial by fire, and the first week with MiG was no exception, finishing up an I’m a Celebrity iPhone app for ITV that unfortunately never hit the app store. It got close, but politics got in the way and it didn’t materialise. A shame, it was a great looking app and had some very cool streaming and voting in it that would have made for a perfect mobile companion to the TV show. But alas, these things happen.

Not all was lost and much of what I ended up learning on this app made its way into Sky’s recent Got To Dance iPhone app. We were lucky with Sky, they were very happy to go with our first set of designs, helping us to help them get the turnaround they wanted. i.e. really really short. It was definitely worth the effort though; the app did well in the App Store Entertainment charts, and the levels of user interactivity for each weekend show were fantastic. It seems people love joining in to vote for their favourite acts through the associated iPhone app. You wouldn’t believe the amount of work behind the scenes to make sure it all ran smoothly week-on-week, but aside from one small hiccup at the start with the CoveritLive stream, it all worked like a dream. A great app to work on, and a great outcome for a great show.

Interspersed in amongst all of these comings and goings was work on the Find a Property app, generally shoring up a rather complex codebase (not entirely surprising considering the project has been passed around several companies before it graced my screen), and adding some cool features to enhance a pretty respectable iPhone app. Hmm, actually I’m underplaying that somewhat, after all it did get onto the Sunday Times Top 500 iPhone apps list.

As did Ministry of Sound’s Ultimate Ministry of Sound app, another project I was lucky enough to have cross my MacBook screen. This app does it all; live radio, ticket purchasing, news, features, video streaming, iTunes track purchasing, there’s really not much missing. If you love dance music, it’s a must-download. I placed my mark on several versions submitted to the App Store before finishing with MiG, the same with Find a Property, before moving on, and it was a pleasure working with MiG, The Digital Property Group and Ministry of Sound (and ITV and Sky of course) pushing everything through efficiently and professionally, as you’d expect with such high profile organisations.

So I’m now back from the Waterloo offices in London, with a short holiday under my belt, ready to push forward again with DigitalOrigins work, as well as that of other clients’. Oh, and the website. I really can’t believe how long it’s been since I’ve touch the website. Just to keep me happy, go check out the apps I’ve been working on, and download them at your leisure. I’ll thank you, MiG will thank you, aww heck, you’ll thank yourself once you have them on your phone. They really are rather good.

Well, I’m not complaining. Their processes have proven as swift as they are true, and CapitaHD is now available for download on what has now become my most prized of household gadgets. If I had to choose between the laptop and the iPad, it might be a close-run thing. Even the kettle and toaster would be on shaky ground despite the usage they both get.

It’s actually been a tough birth this time around though. Not because of the technical light-bending that goes on to get these things done and out the door. In that regard it has been quite the contrary; moving everything over from the iPhone version actually went surprisingly smoothly, the additional screen acreage proving to be such a blessing for the gameplay that I actually ended up adding more polish just out of sheer adoration. No, the creation of CapitaHD just happened to come at a time when time away from work kept popping up (Rome is a delight at this time of the year incidentally), and contract proposals were being penned and meetings had. It can all put a kink in an otherwise extremely productive production house. Fortunately I now have some hugely-appreciated help in that regard so the delays should evaporate into the ether, or so I have been told. Not quite soon enough for CapitaHD to become my first (and hopefully only) victim of circumstance, but welcome nonetheless.

Of course the other knock-on effect of being away is not having been able to put pen to virtual paper. It’s easy to say that the travelling around shouldn’t make things hard when it comes to things like blogging, but, much as I love the iPad, when it comes to pulling together a post, the limitations of the little terrier come ripping round the corner like they’re chasing guinea fowl. Even using my bluetooth keyboard, much as it improves raw text entry, doesn’t do anything to allow me to efficiently cut/paste links, upload images, research notes… The long and short of it is, as soon as anything complicated is required, the MacBook gets fired up, with its trusty mouse, and fancy windowing shenanigans. Not even multi-tasking will change my mind; all I want from Steve Jobs for Christmas is to be able to turn it off on my iPhone. /stares forlornly at every single app permanently running in the background.

Anyway, CapitaHD is available now, so if you fancy a jot of 80s gaming nostalgia, or are looking for a strategy game that’ll work your brain harder than most, go pick it up. Or if you want to find out a bit more about it, you can always head here. And of course don’t hesitate to drop us a line at info@DigitalOrigins.co.uk, or in the comments section should you feel the need. Don’t be shy, we don’t bite.

My inspiration, aside from having done little more with the iPhone other than bleeps and bloops, was the Tenori-on. Now I didn’t know anything about this funky little piece of kit until I saw Jonathan Coulton using one rather expertly at a concert in London a couple of years ago. Apparently it’d been around a while before that, unbeknownst to me. For anyone that hasn’t seen one in action, check out a couple of vids here and here.

Rather than spending a cool grand, I hit up xCode to see just how capable the iPad was at replicating what the Tenori-on could do.

My earlier aural experiences with iPhone have focused solely with OpenAL, simply because it’s easy, it works, and getting it into a game using the plethora of example code and documentation is, to be frank, a breeze. We like OpenAL. The drawback to OpenAL is the lack of control you have over your sound playback. It will do what it wants, when it wants, and how it wants, irrespective of your potentially tight requirements. Fine for a game, not so much for a musical instrument. Besides, at some point there’s going to need to be pitch-shifting involved, so there was always going to be a need access to the sound data itself if I wanted to replicated the Tenori-on’s functionality.

Next up, Audio Queues. Now this is where things start to get interesting. Setting up audio streams and filling output buffers with data manually via callbacks is nothing new, my years of using Microsoft’s DirectSound have gotten me comfortable with such mechanisms. The addition of timeStamps meant that I could set a queue playing, knowing that it would only actually trigger when the timeStamp told it to. Kind of fire-and-forget. Quite neat actually.

The drawback to Audio Queues comes when you want to change the pitch of the notes you’re playing. You can do it when you set a queue up, by simply changing the playback frequency, but only when you set the queue up, not whilst it is in use. So fine, set a queue up, play the note, and delete the queue ready for the next, right? Wrong. Because when you delete an Audio Queue it disrupts the DSP in the iPhone, so if you have any other sounds playing at the time, you get a glitch. The more queues you start and stop, the more glitches you get.

The other issue is, the more queues you create, the slower the playback gets. And by “slower” I do mean “slooowwwweeerrrrr”. A six-note piano chord starts sounding like a guitar strum despite the existence of a timeStamp. Add another couple of notes and you have a significant (in musical realms) amount of time between the first note of a chord and the last. So you have a choice: it is possible to have glitch-less playback but suffer from Audio Queue overload, or you can glitch after every note. Each as unsatisfactory as the other, and both suffer from latency issues when playing back large numbers of voices at a time.

Our only solution lies in the lowest of the low level, Audio Units. Now contrary to popular opinion they’re not actually orders of magnitude more complex than Audio Queues; they still have callbacks and you still have to fill sound buffers manually. The biggest issue with Audio Units is the setting up; they are darned finicky and give little-to-no constructive feedback if you get things out of alignment. Actually, on second thoughts, perhaps I’d better reassess; the biggest issue with AUs is not the setting up, no, the biggest issue with AUs is the considerable lack of clear, concise, descriptive documentation and example code. Admittedly if you want to do exactly what is documented in the way that it has been documented, you’re rocking, kinda. But if you want to step off the beaten track even an inch, and bearing in mind the simplicity of what is documented, you can be sure you’re going to want to at some point, you’re pretty much on your own. Hopefully Apple will make amends soon, but until that time, you’ve got to be brave.

To be continued in “iPhone Audio – Part 2, an exercise in bravery”.

Having spent the last couple of weeks getting Capita onto the iPad, as well as digging my way through the iPhone Audio Queue mire, I think I kinda understand why. The work that we do is, for the most part, utterly absorbing. People talk about “flow” as being something that developers need in order to produce their best work, and when coding, it really is an intoxicating brew. The inevitable downside of flow however is that you can be starting the week reading about buffer sizes, callbacks and latency, and the next time you look up it’s a week next Tuesday. Very bizarre.

And actually particularly problematic when it comes to anything business-related. If you’re running your own show, more often than not you simply can’t afford to be “somewhere else” mentally for that length of time. There are typically too many things that need doing yesterday, be it contracts to chase, accountants to appease, lawyers to pay, and all are eager to destroy the flow that is so carefully cultivated and so ruthlessly defended.

Now I’m reaching the end of both projects I get a chance to sit up and look around, stretch the legs, and put some words onto the screen more of an English bent, a rather pleasant side note to the developing. But the more time goes by, the more I’m starting to think I’m more of an exception than a rule. When caught up in the rush of development, I just don’t think that, for many coders, much else matters, which is why many are only too happy to avoid branching out and away from the work they love.

And the development community is probably all the richer and more productive for it, although I have to say, right now, I think many of us are wondering where on earth the summer went…

When I started iPhone development, the learning curve was relatively shallow; I knew Mac development well enough, and ten years of writing games and tools gets you knowledgable about a whole host of languages and technologies from C++ and DirectX through to 3D engines on the XBox and file converters in Perl. But these handsets are different in a host of ways, and I’d never touched OpenGL before.

To get myself up to speed writing on the iPhone and the OpenGL graphics pipeline, I looked to my gaming past to find something that I wanted to play on the handset. That something ended up being BoulderDash. I grew up playing it on the Commodore 64, and still love it now, there just wasn’t a perfect version for the iPhone. It ended up being a great project to start from scratch, and actually, a great one to finish. It was a real labour of love, never intended for release, which is why it used all the sounds and graphics straight from the c64 version, but boy did it turn out well. Not only does it play identically to the c64 version, it even came with a persistent level unlocking mechanism as well as a high-score / fastest times table. Very neat indeed.

I started iPad development shortly after they arrived on our shores. The iPad and iPhone share operating systems (give or take a few tweaks), but I thought it worth taking something I’d developed for its smaller cousin and porting it across to get a feel for the issues. The perfect candidate? BoulderDash. First on the iPhone, and now first on the iPad. Quite fitting I thought.

I was struck by a few things. Firstly, how quick and easy it was to get an already completed iPhone app up and running on the new hardware. I guess the sharing of the OS helps, but still. The only major issues in fact were the ones you’d expect: the graphics were too small, and the screen layouts broken. It took me roughly six weeks to go from zero to a complete ready-to-release version of BoulderDash on the iPhone, but approximately 3 days to port it to the iPad up to the same standard (along with a few additional bug-fixes along the way). That’s very cool indeed.

The other thing that struck me was just how exquisite the game actually looks and feels on the bigger screen. I really do love the iPad, and there’s some great games for it, but to create something yourself and see it rendered in such finery really is something else. So much so that I’m actually considering releasing it under DigitalOrigins in some form. Even if I have to replace all the sound and artwork and change the name to something like DiamondRush (which I actually rather like), I think it would be worth having this in the hands of people so that they can get some enjoyment out of it.

Perhaps now is the time to commission some artwork. Anyone up for the task?

Of Apple’s three current cloud offerings, MobileMe is probably the most notorious, having been around for rather a long time now, first free, then not, then given an overhaul, repackaged, and again dutifully ignored by many of their faithful.

iTunes and the App Store have, in contrast, seen meteoric rises to fame over a very short period of time, enabling Apple to deal first in music, then video, and now in pretty much anything from books to pdfs as well as apps from the newly tagged-on app store. Despite its rather outdated and inaccurate nomenclature, iTunes really is pretty special, particularly for Apple, but it is merely the start of things to come.

Now, buried within the settings of Apple’s recently updated iBooks app, you can switch on “synching”. This rather innocuous feature may not seem particularly significant when iBooks is used on a single device, but used on both an iPhone and an iPad you now have the capability of reading a book on one that then automatically updates the current page on the other wirelessly with no user intervention required. The synching technology behind the scenes? Your humble iTunes account.

Quietly, and rather nonchalantly, Apple has slipped its first piece of MobileMe-esque cloud communication and synching technology into iTunes, at this stage giving them a small test bed to enable them to eek out any behind-the-scenes issues, but ultimately giving them one hell of an expansion opportunity.

And expand it they will, because right now they are staring down the barrel of two cloud technologies. MobileMe, has a subscription fee, has become a little crusty and underpowered, has low uptake and is desperately in need of a revamp to keep it inline with its competitors. The second, iTunes, well, nearly everyone has it, nearly everyone has an account with it, nearly everyone likes it, and it is far in advance of the competition, whilst being completely free. And now it is starting to be used to delve into the world of wireless synching across the multitude of Apple devices.

It would seem that Apple are readying themselves for one rather awe-inspiring software merger, and with the new data centre later this year, they will finally have the capacity to make it a success. And it’s a smart move. They have consumer’s homes in the palms of their hands right now, and a multi-tiered move like this would very quickly shore-up their advantage against the likes of Google who are desperately trying to get a foothold into an extremely lucrative technology segment.

So, renaming iTunes to iMedia, folding the current MobileMe offerings into it, and pushing forward on not just app synching, but full multi-device, multi-OS synching, along with cloud storage for all, with access to all personal documents and data, all of the time, wherever you are in the world on whatever device you have to hand, and, well…

Kinda takes your breath away, doesn’t it?

But behind the scenes, what makes the magic happen? How can a company like DigitalOrigins turn an idea into a killer App?

First off, we like most companies, brainstorm an idea with a client and mould it, poking and prodding until we understand everything our client is aiming for. Here it’s about aims, not techniques; as long as the aims remain true, the techniques can be whatever is required to get the job done. Once the aims are understood, we start on a simple design and prototyping loop to help contextualise those aims and bring them into something that the client can actually experience. Here we’re simply creating bare-bones interfaces and workflows to illustrate areas of contention, and generate simple movement through an App giving a feel for what could be expected at completion. Things not feeling quite right? Back to the design phase. The idea not quite as strong as expected? Tweak the idea and adjust. As any professional developer will be able to tell you, getting aims and objectives right here, saves time, money, and a whole heap of heartache later. By the time we’ve reached the end of this process, we are in a great position to make time and cost estimates and draw up a general development plan.

Now some companies move onto full development fairly early in this design phase, preferring to hone and adjust details and timescales whilst full-scale development is in progress. These agile-focused companies tend to prioritise the maintaining of close ties with the clients, working alongside them on a short but regular basis to ensure that the design matures over time like a fine wine, and as new features are designed and implemented, they are demonstrated, discussed and adjusted where necessary alongside cost and timescales. I personally like this way of working; it builds trust early on in the development cycle, and lays the foundations for strong communications and relationship-building throughout the project, two major features inherent in any successful contracting project. The drawback is that the cost-estimates and development plan become less black-and-white, only natural when building in the ability to adjust mid-flow. My experience has shown though that the additional transparency and flexibility more than makes up for this rather more “fixed” planning process, even if it can be somewhat less predictable.

Whichever way the company chooses to work, the development phase is where the aims, the design ideas, the code and the artwork are all brought together piece by piece, tested, demonstrated and added into the coherent whole, building the core app up slowly over time. This is a good time, a time of communication and sharing, a time of changes, adjustments, of iterating, but of ultimately moving forward and creating something special. I have yet to find anyone that didn’t get a buzz out of this phase; being able to create something out of nothing with a client really can be a rather invigorating process for all involved.

Once iteration has produced an app that hits all the aims (adjusted and tweaked where necessary during the development phase), the product is nearing release. For most development companies this is the application’s Beta phase, the phase where the app is poked and prodded from all directions, squeezed over and over to force bugs from the system. For some it is also an opportunity to add polish, to add speed where necessary, to add that final layer of gloss that turns a good product into something great, all before sign-off and handover take place.

And for many this is the ultimate goal; completing Hogs of War for Infogrames simply saw the handing over of the gold-master followed by a project post-mortem before moving onto the next project. For others this is just a step along the overall project lifecycle; NavisWorks saw this sign-off process as simply a gate to move through prior to further design, development, testing and release iterations. With today’s electronic distribution, particularly with the App Store enabling ongoing feedback and bug reports, as well as bug fixes, additional features and further releases, all within relatively short timescales, it makes sense to have this milestone as a more open-ended project goal. But at some point the first release must be pushed out, to the clients, to the public, and this is where it happens. Simple.

To some it may seem like a rather complex process, but actually, when working with a good professional software company, one who wants to work with you rather than just for you, much of these elements are managed behind the scenes, and, from a client’s perspective, the whole process can tend to flow rather gracefully. I’ve worked with many companies over the years that have marvelled at just how smooth and efficient the whole process can be. The key? Work with someone that knows what they’re doing, someone who wants to work with you not just for you, and someone that has a passion for making something that’s great, rather than just making something.

As I’ve always found, follow those three elements and you really can’t go to far wrong.