As you may have already heard by now, Apple has announced a new programming language called Swift. It’s modern, powerful, and potentially easier to use than Objective-C. In fact, from the time I’ve spent tinkering with it, I’d say that those coming from an ActionScript or JavaScript background should find Swift a much more approachable language. So if you’ve always wanted to develop iOS and Mac OS X applications then this might be the ideal time to jump in.

I had a bit of spare time over the last few days so thought I’d flex my programming muscles and port the parallax scroller from my endless runner demo to Swift. Truth be told it was a fairly straight forward process and I’m looking forward to spending more time with the language over the coming months. If you fancy taking a look you can find the source code on GitHub: https://github.com/ccaleb/endless-runner

It’s also great to see a few familiar faces from the Flash community picking up Swift and blogging again for the first time in a while. Adobe’s Thibault Imbert has blown the cobwebs off his ByteArray blog and has already posted several great Swift tutorials for those coming from an ActionScript background. Lee Brimelow, who also works at Adobe, has set up a new blog dedicated to Swift tutorials, which is definitely worth checking out.

If you’re interested in learning Swift then Apple’s Introducing Swift website is a good place to start.

There are new Star Wars films on the horizon and I’m pretty damn excited by that. In fact I’m so excited I decided to re-write my X-Wing Targeting Computer app for iOS. Yay!

You may remember the original ran on Android handsets and was written using Adobe AIR. This time I thought I’d go native and write it in Objective-C. I also thought the app needed a lick of paint too so enlisted the help of my sister-in-law who very generously offered to spend her very limited free time making it all look a bit more modern. I’m sure you’ll agree it looks awesome!


You may be thinking why I bothered with Objective-C. After all, since the Android version was written in AIR, couldn’t it easily be ported to iOS too? Yup, it definitely could, but I don’t do nearly enough Objective-C stuff and thought the app gave me the ideal excuse to do some more.


If you aren’t familiar with the original version, it’s a simple GPS-enabled app that lets you pretend to be an X-wing pilot while you’re driving your car. It’s really easy to use. Just lock in your target location and start driving until you eventually reach the exhaust port, er, I mean destination. Your distance to the target will be continuously updated as you drive and you can even hear radio chatter from your fellow pilots!


Just like the original version, I have no plans to release it on the App Store. I strongly suspect I’d have the same problem convincing Disney to release the app as I did with Lucas Licensing previously, so I’ll leave it as a nice portfolio piece.


I’ve added a video at the beginning of this post where you can see me giving it a quick spin. I couldn’t be bothered actually driving around in my car with it (you can see a video of me doing that with the original Android version here) but you can see it run in demo mode to give you an idea of how it works.

Now that that’s all done and dusted it’s time to start learning how to program iOS apps in Swift. Anyway, may the Force be with you guys. Always.

Over the last year or so there’s been much talk from the community regarding the need for the integration of native physics within the Flash runtime. Adobe’s Flash product manager, Chris Campbell, has opened this up for further discussion on the Adobe Communities forum.

Personally I think this might be a good thing as Adobe has been saying for some time that gaming is now the primary focus of Flash and AIR. However, I really only want to see this happen if adding a native physics engine would provide superior performance over and above using a third party ActionScript library. I’d also only really be keen to see this happen if Adobe were committed to frequently maintaining and updating the API. Finally, I’d prefer that API to be either Box2D or something that’s very similar to Box2D. My reason being that Box2D is a very popular and well document API. I’d rather work with an API that’s well known and already has a wealth of tutorials and resources out there that I can already benefit from.

Anyway, if you want your say in the matter then head over to the Adobe Community Forums and add your tuppence worth.

stored in: HTML5 and tagged: , ,

Isn’t Unity awesome! For 3D games developers it’s probably one of the best choices out there and seems to run on just about any hardware platform you can throw at it. Now with Unity 5, things are getting even more awesome as it now targets WebGL, removing the need for the Unity browser plugin.

So how does all this work? Well basically the Unity runtime code needed to be cross-compiled to JavaScript allowing it to run in your browser. This was done using emscripten to convert the runtime’s C and C++ codebase into asm.js JavaScript. I’ve mentioned asm.js a couple of times before. It’s an optimised subset of JavaScript that can be AOT-compiled by supporting browsers into native code. The beauty of asm.js is that being a subset of JavaScript, it will still run on browsers that don’t directly support it ensuring a level of cross-browser compatibility.

Of course, Unity game code itself is written in C# (and UnityScript) and compiled into .NET bytecode. That bytecode also needs to be converted to JavaScript before your game will run in a WebGL enabled browser. To achieve that, the Unity guys developed a new technology called IL2CPP, which takes your game’s bytecode and converts it all to C++. Emscripten is then once again employed to convert all that to JavaScript.

Phew! Sounds pretty technical but it results in your Unity games being able to target WebGL compatible browsers and that’s a very exciting prospect for many. Theoretically your games will run on browsers and platforms that don’t have support for the Unity browser plugin. For example, this could open up Unity games to Android phone and tablet owners wishing to play games within their browser rather than downloading apps. And if Apple ever bothers to support WebGL on mobile Safari then we could also see Unity games running in the browser on iOS.

It’s early days yet and Unity’s WebGL support is still in Early-Access. However I was able to run and test a few demo games on my Macbook using Safari. I must say, I was very impressed. If you fancy taking a look then try out both Dead Trigger 2 and AngryBots, which show off the technology’s potential. Great stuff!

Now I wonder if Adobe will go down the same route with Flash and break away from its dependency on the browser plugin. It could breathe new life into the much-maligned runtime and give Flash a wider reach on mobile phones and tablets.

stored in: AIR and tagged: , , ,

I’ve come across quite a number of Adobe AIR games over the last few months so thought it was about time I did another round-up. There’s actually too many AIR games out there these days, particularly on mobile, so unfortunately I can’t cover them all. However here’s five that caught my eye for one reason or another. There are a few more I’ll cover in a future post but if you’re an ActionScript 3 programmer and you use frameworks like Starling and Away3D then the following games should let you see what others in the community are capable of.

Groove Racer

I downloaded Groove Racer almost a year ago and didn’t realise it was written in Adobe AIR! It’s a gorgeous little racing game that recreates the thrills and spills of Scalextric tracks right on your iPhone. Controls are simply a case of holding your finger on the screen to force your car to accelerate. If you want to beat your opponent however then you’ll need to carefully judge your speed coming into the bends. With 10 unique cars across 66 imaginative tracks there’s plenty to keep you entertained for some time. Download Groove Racer for iPhone, iPod touch, and iPad from the App Store.

The Banner Saga

The Banner Saga is a truly epic tactical role-playing game inspired by Viking legend. It’s also a game of choice, where a poorly judged decision can see your caravan suffer or even seal the fate of individuals you’ve grown fond of. When you’re not spending time managing, you’ll be engaged in the game’s grid-based combat desperately trying to win victory in order to push on for another day. It’s a stirring game that gnaws at your emotions, taking you on an epic journey through beautifully crafted hand-painted landscapes. The Banner Saga is available for Windows and Mac. Also, if you want to know more then take a read of both Eurogamer’s and IGN’s reviews, which do the game much more justice than my brief description ever can.


Here’s another beautiful 2D platform/puzzle game written in AIR. Guide Hilomi, the game’s heroine, through each level taking photographs of the unusual wildlife that inhabits her world. Hilomi needs help traversing each level’s environment and that’s where you come in. You can deform the terrain with your fingertips: moving earth, creating bridges, digging tunnels, and commanding water and fire, all in a bid to get Hilomi to each of the animals she wants to add to her photo collection. While the initial dozen or so levels are pretty easy, the game’s difficulty soon ramps up making it a great distraction for anyone who likes puzzle games, like my girlfriend who’s sitting next to me desperately trying to figure out how to get onto the next level. Hilomi is available for iOS from iTunes and Android via Google Play.

Zombie 300

Zombies have invaded your mobile screen! Use your fingers to crush them and save the humans. It’s more or less that simple in this delightful little game for iOS and Android. Of course other things have been added to the mix to provide more depth including: power-ups, a collectible currency system, and innocent bystanders. During the heat of the action it’s quite easy to confuse bystanders with the zombies, which quite often results in humans getting accidentally crushed into the ground. Given the fact that all the humans in the game are represented by schoolchildren it’s all the more heartbreaking when you crush one. My little nephew loves this game, and the distraught expression on his face when he accidentally crushes a boy or girl is priceless. Zombie 300 is available on iTunes, Google Play, and the Amazon App Store.


I think CUBD can best be described as a brain-bending 3D puzzle game that’s inspired heavily by the Rubik’s Cube and match-three games. With a simple flick of your finger you can turn and twist your cube in an attempt to match three squares of the same colour. You’ll need to be quick though as you’re up against the clock, and the only way to gain more time is by finding more and more matching colours. It’s both challenging and addictive and things start to really heat up when you’re running low on time. If you’re a fan of puzzle games then you’ll certainly find yourself coming back to CUBD time and time again. It’s available for iOS on the App Store and Android through Google Play.

I was really lucky to get the opportunity the other day to attend a lecture by Bjarne Stroustrup, the creator of the C++ programming language. He gave a really insightful talk about the history of C++ and covered some of the major additions coming to C++14. He also spent some time highlighting common mistakes and bad practices before talking about how to actually do things right.


Andy (look at that grin), Iain, and Amanda getting pretty excited.

I haven’t written anything significant in C++ in years and thought that Stroustrup’s talk might give me the kick up the backside that I needed to spend more time with it. I definitely came away from the talk feeling inspired but I did learn that I’m most probably a very bad C++ programmer and also that the language has moved on quite a bit in the decade or so since I last used it in anger.


The man himself.

While I did enjoy myself, the evening was really for the hardcore C++ developers out there. My buddy, Angry Andy, is one such developer who eats, sleeps, and breathes C++. He loved every minute of the talk and had the cheesiest of grins on his face during the whole two hours. As an added bonus for the evening, I spotted one of my old university lecturers, Duncan Smeed, who was one of the co-creators of the Dragon 32 home computer. How cool is that!

Okay folks, that’s a first pass at the Objective-C version of my endless runner’s parallax scroller. I’d been meaning to take a look at SpriteKit for a while now so thought I’d use it as my rendering option. I was thinking about targeting the full range of iOS devices (Retina and non-Retina iPhones, iPads, and iPod touches) but in the end opted to just target a single resolution (iPad non-Retina) to keep things consistent with the other languages that I’ve used so far. You can find the source on GitHub.

So that’s my parallax scroller now implemented and running in four different languages:

  • JavaScript
  • TypeScript
  • ActionScript 3
  • Objective-C

If you need some more detail regarding the scroller’s implementation then take a look at the four-part tutorial I wrote for the original JavaScript version:

Building a Parallax Scroller: Part 1
Building a Parallax Scroller: Part 2
Building a Parallax Scroller: Part 3
Building a Parallax Scroller: Part 4

The implementation details are almost identical for the other three languages so you should still find the tutorial useful even if you aren’t interested in JavaScript.

So what’s next? I may add a few more languages and/or renderers to the mix over time, but my immediately aim is to add a game character that can run and jump between platforms. I’ll keep you guys posted.

So that’s the ActionScript 3 version of my endless runner on GitHub. The JavaScript and TypeScript versions both used PixiJS as the 2D renderer, but of course, for the AS3 version I’m using the excellent Starling Framework.

If you’ve been reading my blog for a few years you’ll know that my endless runner actually started life as an ActionScript and Starling project (see video above). However my original code was a mess and it has taken me ages to actually get around to tidying it up enough to put it on GitHub. As I said in my previous post, I’ve just started by concentrating on the parallax scroller. I’ll hopefully add a game character and physics integration into each version over the coming months. Before I do that though I’d like to port the scroller to at least one more language. Think I might go with Objective-C.

I’ve decided to port the source code from my Building a Parallax Scroller tutorial to various other languages, starting with TypeScript. I’m hoping that it will eventually evolve into more than just a parallax scroller and we’ll end up with a very simple endless runner game but that’s for a little further down the line. So to begin with I’ll simply focus on the scroller.

So to begin with you can find my TypeScript port sitting alongside the original JavaScript version on GitHub at: https://github.com/ccaleb/endless-runner. Both use pixi.js as the 2D rendering engine.

If you haven’t seen my original four-part tutorial then you can find links to it below:

Building a Parallax Scroller: Part 1
Building a Parallax Scroller: Part 2
Building a Parallax Scroller: Part 3
Building a Parallax Scroller: Part 4

Next up will be an ActionScript 3 version.


It has been available since AIR 4.0 but I’ve held off covering AIR’s improved packaging engine for iOS due to a major bug at the time. Thankfully it seems to be fixed in the AIR 13.0 beta (yup we’ve gone from 4.0 to 13.0 in one step) so I thought I’d take the packager out for a spin on a couple of projects.

Adobe claim that the packaging times can now be up to 10 times faster than the old packager. Here’s my findings from packaging two separate projects on my ageing PC with its i3 processor: WeeWorld’s MatchMee app and my Monster Dash clone.

Project Legacy Packager New Packager
Match Mee 2.10 mins 52 secs
Monster Dash 2.06 mins 16 secs

As you can see, both projects packaged significantly faster using the new packager. Match Mee’s packaging time was roughly half that of the old packager’s, while my Monster Dash clone saw a reduction in packaging time that was actually not far off Adobe’s bold claim of being up to 10 times faster.

I was hoping that Match Mee would see improvements similar to my Monster Dash clone’s packaging times, but as it stands we’re still looking at times close to a minute, which is still far from ideal. I’m not sure what’s causing the difference in times between the two projects but Match Mee does have 7 SWC files statically linked to it along with 4 native extensions so perhaps that’s what caused the longer packaging times.

Either way though, the new packager brings a significant reduction in times and is a welcome addition.