This is a personal blog. The opinions expressed here represent my own and not those of any of my employers or customers.

Except if stated otherwise, all the code shared is reusable under a MIT/X11 licence. If a picture is missing a copyright notice, it's probably because I'm owning it.

Thursday, September 26, 2013

SpriteKit on Xamarin.iOS: fun without compromise

TL;DR: get the source of the game on github.

With the release of iOS7, and same day support in Xamarin.iOS, I'm spending all my free time playing with the new APIs. I particularly love iBeacon and Background Fetch. Next on my list was SpriteKit.

SpriteKit is a 2D game engine, not unlike cocos2d at all. We'll see next that it's going from one platform to another is very simple.

 I'm not a game developer, but I have some experience with cocos2d as I co-wrote (with Miguel) the cocos2d bindings for Xamarin.iOS. At that time, to test the binding, I ported a sample platform jumper game from obj-c cocos2d to c#. And I again ported the same game to SpriteKit. Here are my findings about the experience:

The Pros

  • you can almost to a line by line port between cocos2d and SpriteKit, once you figure out the basics
  • less boilerplate. Or even no boilerplate at all with SpriteKit. a SKView is a UIView, and is ready to serve as soon as you PresentScene() it. Compare that with the directors you have to put in place before writing a line of game logic in cocos2d. It's a win.
  • less leaky abstractions. I haven't compared performances, but SpriteKit doesn't expose stuffs like BatchNodes, so it's one stuff you don't have to bother about.
  • SKAction is a nice addition for objects you don't want to animate yourself in your Update() loop (they're executed just after Update(), and before physics simulation)

The Cons

  • I found myself looking for BitmapFonts. It seems like a standard in game development, but missing from SpriteKit (or I haven't found it). I'm quite confident that's a stuff we'll see in an upcoming new version.

The Rest

  • As the original game, this port doesn't leverage any Physics engine, so I have nothing to say about SKPhysics* stuffs. From the API, it looks very similar to what Chipmunk offer.

So it was a very pleasant port, at the end taking even less lines of code than the original port, and only 2 hours to write. If you want to start developing games, going for SpriteKit on Xamarin.iOS is really a no brainer. No boilerplate, no gotchas, just fun.

The Code

The code is on github, it's MIT/X11 so do whatever you want with it. The graphics are borrowed from the original game, read the LICENSE about their usage.

Tuesday, September 24, 2013

Xamarin.iOS 7 : iBeacons - Part 1: Advertizing

One of my favorite new feature of iOS 7 is the addition of iBeacons. You'll find plenty of articles explaining how it'll change the way you do shopping (if you still shop offline), allows indoor localization, and even more. Glue a beacon on your kids, and you'll know when they go too far away (digital leash). Attach one to your wallet and your phone will tell you you're leaving the house with no cash. Applications are endless.

iBeacons is a protocol on top of Bluetooth LE (Low Energy, also advertised as Bluetooth Smart, and part of the Bluetooth 4.0). It doesn't require any new hardware and is nothing really new by itself. What's new and exciting is its position in iOS: first-class citizen, integrated with CoreLocation, working in the background, ...

The recipe: advertising your position

As of now, the only objects you can use as iBeacons are iOS devices. The protocol should be made available soon, allowing 3rd party components to appear, and at that time they should sell for a few dollars a piece (based on a general purpose BT chip, like the BLE112, a beacon should cost around 40$ to build. Prices will surely drop by using cheaper and specialized chips).

Turning your iOS device into a beacon is really only a few steps:

1. Initialize a CLBeaconRegion

That'll be your beacon. uuid and identifier are mandatory. Major and minor are optional. There's a trick here, uuid doesn't have to be unique. All beacons of a common group will probably have the same uuid, and different major/minor versions.

var beaconId = new NSUuid ("5a2bf809-992f-42c2-8590-6793ecbe2437");  //uuidgen on MacOS, nguid in VS
var beaconRegion = new CLBeaconRegion (beaconId, "yourOrg.yourBeacon");

2. Initialize a CBPeripheralManager

var peripheralManager = new CLPeripheralManager (new PeripheralManagerDelegate(beaconRegion), DispatchQueue.DefaultGlobalQueue, new NSDictionary ());

class PeripheralManagerDelegate : CBPeripheralManagerDelegate
    CLBeaconRegion beaconRegion;

    public CBPeripheralManager (CLBeaconRegion beaconRegion)
        this.beaconRegion = beaconRegion;

    public override void StateUpdated (CBPeripheralManager peripheralManager)
        //State will be Unsupported on devices like iPhone4 and prior, PoweredOff if BT is down
        if (peripheralManager.State != CBPeripheralManagerState.PoweredOn)
        var options = beaconRegion.GetPeripheralData (null);
        peripheralManager.StartAdvertizing (options);

And that's it.

Notes and further reading

  • As devices BT ids changes from time to time, your device will be sometimes advertised twice. That won't happen with real iBeacons.
  • If you want to advertize in the Background, enable "Acts as Bluetooth LE accessory" in your info.plist
  • Read Region Monitoring if you need more details.