jerakeen.org

While passing through an airport recently I bought myself a new Nintendo DS Lite, and Ninja Gaiden - Dragon Sword. I’m not going to bother reviewing it - I’m bad at that. But I loved it, in large part because I enjoyed playing the Xbox version ages ago (it was hard) and it plays very similarly.

The whole thing controls with the stylus (and holding any button, which blocks) and it all feels so fluid. It retains the feeling I remember from the xbox, which was that you were always moving somewhere, hitting things, but it never really felt that things weren’t under control. I’m impressed that somehow the two games play so similarly, given that the control scheme is so vastly different. All the same things worked - Flying Swallow still works well on certain sorts of enemies, others need proper block/attack synchronisation, collecting essence still works the same, you still have an annoying motivation to find a good group of respawning enemies next to a save point and farm them for money till you can buy all the upgrades… And the camera is a pain, though much less of one than in the Xbox version. It’s a fixed viewpoint, and pans, which works well except when you’re far enough away that it’s hard to judge depth and you’re flailing away at things you can’t hit.

It’s a lot easier and smaller than the first one. It’s still linear, but has a hub-and-spoke level design, a central area from which you open progressively more portals. I preferred the Xbox game, which had a long linear-ish progression that looped back on itself, bringing you back to old areas sometimes, but never in a way that made you feel that they were hubs. Well, maybe once. Being given a list of ‘here are the portals that you’ll be able to open, you’ve opened these, this one is next’ feels like a cheap way of indicating progress through the game. Maybe people like this sort of thing. But the Xbox version felt better as a story telling vehicle.

Anyway, I liked it.

13:19 <@jerakeen> I have worked out how to syndicate my WOW achievements into my jerakeen.org lifestream.
13:20 <@The> it's becoming a "no life" stream

The iPhone iPod ‘podcast’ section used to list video podcasts, but only played their audio tracks, which was odd. Now (as of the 2.2 firmware) it’ll play video podcasts as well, which is nice. For a start, I can take the ‘video’ button off the tab bar at the bottom and free up a slot for something more important.

Weirdly, it’ll play the video in portrait mode (as well as landscape mode), whereas the video section of the application will still only play them in landscape mode.

Startlingly, the webkit-based browser on the iPhone supports the HTML 5 client-side storage standard. Alas, you can’t write properly off-line apps because there’s no local HTML/file cache on the phone you can keep files in. You could use the bookmarklet trick I suppose, but I don’t like that one - it’s nasty, and makes development annoying - you have to keep re-syncing things, it’s not terribly easy to upgrade, etc.

I do, however, want to write local apps in a language that’s a little higher-level than Objective-C. It’s nice and all, but I prefer things to be more flexible. The iPhone SDK agreement means that I can’t write my code in a high-level language and ship an interpreter, alas - no iPhone pyobjc for me. But (and this is speculative, I’m not a lawyer, etc etc) as I read the iPhone SDK user agreement, I think you could probably write a pure HTML/JavaScript application, using the webkit local storage engine, and run it in an embedded webkit view as a local iPhone application.

“

3.3.2. [..] No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

”

(emphasis mine)

This means I can have a shippable application, with local storage, but with large bits of logic written in JavaScript. I may even be able to intercept requests for urls and call API functions from Objective-C space, so I can expose location data to the application, for instance.

There are obviously huge disadvantages to writing an app in HTML, but I’d like to try it if only as both a rapid prototying environment for local apps, and a way of giving apps that are already HTML-based some local storage and the ability to be run when away from network.

Unfortunately, I feel that I can see where this could get taken. The spirit of the SDK agreement is clearly that Apple don’t want any way of distributing applications except through the App Store. This exception is in the SDK only because you can’t have an embeddable web browser widget without saying ‘stuff the web browser does is ok’. But if this loophole actually is a loophole, I don’t see what stops me writing a front-end that can download more HTML into the local storage area.

Well, no, actually, I see

“

3.3.3 Without Apple’s prior written approval, an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store.

”

..which might cover that one. Maybe I’ll write something like this as an experiment anyway.

Here’s another thought. If I can intercept requests and call Objective-C functions, why do I need the HTML-displaying part of this at all? How introspectable is Obj-C anyway, and can I ship an Objective-JavaScript bridge in my app?

The video everyone is watching, apparently. Also, there are lasers! But I like the little QR code machined into the inside of the body. Awwwww.

http://www.apple.com/macbook/#designvideo