I worked on a project[0] very similar to this just recently. It's definitely not as nice as this, but it's got the added advantage of being able to use javascript events to-spec, and the only lines in your game code are these:
iPhone = new Controller();
iPhone.on('touchstart', function(event) { /*...*/ }
That's the entire API ;)
I'm in two minds over the use of QR codes here. I had two solutions to the problem of pairing browsers: as I do it now, I ask for a pairing code. Another, more hacky (but possibly nicer) solution is to assume that if a controller and a parent browser have the same external IP, you can assume that they want to pair up.
Anyway, kudos to the developers - it's a really cool idea, I think. If my code can help out at all, please go right ahead :)
(also sorry for hijacking your thread)
iOS only? Meh. It really is true: iOS is the new MSIE.
Somewhere down the road iOS-only code will not be accepted, and then we have tons of code already deployed which will never work on anything else, unless Apple's non-standard JS and webkit extensions are accounted for in other browsers.
This is hopeless and pathetic. And HN will love it.
There are some very good reasons that, despite IE6's popularity and extreme market share--both larger than iOS, I believe--everybody else did not adopt IE6-only "features" like ActiveX as standards.
I don't understand why fun projects can't just be fun projects...why does everything have to be interpreted as some sort of statement concerning the state of the web?
Also no websocket support in Android browser yet (http://caniuse.com/#feat=websockets). This makes things a little less ideal for realtime gameplay (even with the fallback options provided by socket.io).
Should also note that DeviceOrientation (aka "accelerometer in the browser") is in Android 3.0+ (although that doesn't do much for most of the devices out there).
Not working with my iPhone 4. Paired successfully with the game and Safari was showing the accelerometer values(which changed as I moved the phone) but my ship wouldn't move no matter what I did.
The game starts with a landing page (as in the link). After pairing is done then the browser will automatically redirect to the game page. Did that happen for you?
That happened, but it doesn't actually seem to accept the info from the iphone. I see the accelerometer readings on the iphone, but it doesn't seem to do anything with the page. I tried reloading the page on my laptop and on my phone. Best I could do was get it to move all the way to the left once and then just hang there. Neat idea, hopefully you can fix it.
Not working for me either, but my desktop browser has to go through a proxy at work. I suspect that's what's wrong here. I will try it again at home later.
I built a slideshow control system for a class project using nearly the same approach. A user uploads a slideshow or authors it online and connects a phone/device via a QR Code or URL to control the presentation. The controller uses websockets to communicate with a nodejs server for events like previous/next, a touch-screen based laser pointer, and presenter notes. I was amazed how responsive the touch movements translated to moving a dot on the screen through a remote node server.
We didn't use any accelerometer events, but touch events worked seamlessly on iOS and Android.
We're doing the same thing at Brass Monkey, raised our seed round and are trucking along with lots of features. Hope you guys check us out to. Checkout our website and video demo.
http://playbrassmonkey.com/
True dat. We require a Controller app to be downloaded. But then we have auto-pairing tech. We have more than just HTML5 game support. But Flash and Unity Webplayer games as well.
I have been working on this similar idea for more than a year now. Really glad seeing more people are interested in this. Ping me if you are interested in chatting a little more about the project.
34 comments
[ 3.6 ms ] story [ 86.9 ms ] threadI'm in two minds over the use of QR codes here. I had two solutions to the problem of pairing browsers: as I do it now, I ask for a pairing code. Another, more hacky (but possibly nicer) solution is to assume that if a controller and a parent browser have the same external IP, you can assume that they want to pair up.
Anyway, kudos to the developers - it's a really cool idea, I think. If my code can help out at all, please go right ahead :) (also sorry for hijacking your thread)
[0] https://github.com/CarlQLange/Controller.js
Somewhere down the road iOS-only code will not be accepted, and then we have tons of code already deployed which will never work on anything else, unless Apple's non-standard JS and webkit extensions are accounted for in other browsers.
This is hopeless and pathetic. And HN will love it.
The current direction does seem to be towards end-of-lifing the Android browser (and ChromeOS) and moving Chrome in as the default.
http://caniuse.com/#feat=deviceorientation
I solved the latency problem by using websockets. I know, it's not a widely used standard but was good enough for a weekend project.
http://demos.clikthis.com/ethershock/
I think they have an Android/iPhone companion app that works for these types of web apps.
We didn't use any accelerometer events, but touch events worked seamlessly on iOS and Android.