I think this is the first time I've been genuinely impressed with a Chrome Experiment.
They've recreated Super Monkey Ball entirely inside the browser, with the option of using a device as a controller. Certainly an interesting concept for multiplayer gaming, imagine Chrome running on a Smart TV(Chrome OS TV?) and a couple of friends can hook up their mobiles as controllers, and play some casual party style games like Monkey Ball or Mario Party.
Yes, that's what I've been dreaming of ever since I first saw a smartphone. I'm very surprised it isn't as obvious to other people how cool it would be. The smartphone is the perfect game controller.
For example a strategy game played on a TV together with friends where each phone is not only used for controls but also showing (private) game data and more!
No, it's not a perfect game controller. A convenient one maybe, but not perfect, not even good.
It has the same problem that you would encounter if you tried touch typing on an iphone keyboard. It has no physical feedback so you have no idea if you are pressing the correct button (or any button at all) on the phone screen unless you are actually looking at it. Which means you won't be able to look at the TV screen at the same time.
When my iPhone 3G's screen broke, the bottom part of the LCD broke--just enough to cover the keyboard. I was abroad, so for the month until I got home, I learned to touch type on my iPhone.
Yeah, you're right. I was thinking in terms of a traditional console game controller. A phone has other features that could be used like speakers, microphone, accelerometer, etc. As a motion device it would be great, definitely.
I agree. It is perfect for games which rely on the idea of positioning your hands. It's really just a tool for the idea of moving the world with your hands. In this case it's perfect.
Personally I hate the PS3 controller as it's too small, I much prefer the xBox 360 controller and especially if it has the keyboard attached to it.
Also, on the iPhone I dislike 99% of the games that use a virtual joystick on the screen, I just can't get on with them.
But for touch interface games, what the parent post says is a joy I look forward to experiencing: A game with discreet information on the hand-held device.
A touch screen certainly isn't for 60fps twitch-gaming in my opinion.
> But for touch interface games, what the parent post says is a joy I look forward to experiencing: A game with discreet information on the hand-held device.
I think it would suck compared to a traditional game controller, if it were to be used as a traditional game controller. As say, a motion device, it could probably work just as well as any other controller.
But there are of course ways to improve the experience.
For example, you could show the visual feedback on the TV itself, so you can see where you are touching relative to the display. Similar to how the Kinect shows where it thinks your hands are.
YOu need to take a second to think about what Google is doing here. Again, Google is being clever about getting data from you. Take a moment and ask yourself why they're doing this...
Google want to connect your browser information with your phone information. And they're doing a good job.
This is kinda different in that the mobile device doesn't need a custom app on it to act as the controller (as in your Brass Monkey example), but can act as the controller directly within the browser. No extra installations, just hit up the website and go.
I'm the CTO at Brass Monkey. We definitely experimented with this approach of using a webpage and websockets to communicate, it is nice that it doesn't require installing an app but it communicates via relaying messages out to the internet and back and so generally has latency in the 100ms+ (<10FPS) range and usually worse. See early video I made at a previous Company using HTML5 for controllers: http://www.youtube.com/watch?v=NE8-TntjYB4
With Brass Monkey we decided to instead make a single master controller app that used a trick we discovered to communicate over LAN between your phone and PC, this way it's blazingly fast. Can be more like 10-20ms (100-50FPS) instead and more consistent.
You only have to install it only once and then you can play any Brass Monkey experience seamlessly, including auto-pairing tech that detects other instances of Brass Monkey enabled web pages on your network.
Note: There are still major advantages to the web based approach such as bypassing Apple's approval process. It's hard to have controller side code executed unless you bake into your app as Apple doesn't allow dynamically loading code into native apps. But we decided to go responsiveness for our initial focus and are trying to figure out how to bring in some of the other benefits the web page as controller approach takes.
Would love some feedback on our App if you are games, orSDK if any of you are Javascript, Flash, and/or Unity developers.
> a trick we discovered to communicate over LAN between your phone and PC
Wow! Could you please tell a little more about the trick? How does a LAN connection between your web app in the browser and your iPhone app work? Do you create a locally accessible web server from your iPhone app?
The reason this is so impressive is that it brings together three technologies that people aren't used to even seeing one good implementation of yet:
* HTML5 accelerometer support
* Sync between mobile/desktop using websockets
* Web page slicing based (by the look of it) on DOM and image processing
…and of course this is in a nice responsive WebGL-rendered package, which people are getting more used to thanks to the http://www.chromeexperiments.com/ project.
The reason I am impressed is the game is playable even though the control loop runs through a telephone company, Google's servers in god-knows-where, and back to my PC.
Well, good is bit of a stretch. On first try I got disconnected during loading the level. On the second the level loaded but accelerometer does not work, only the buttons do. Also the screen on the phone (Galaxy Nexus) is upside down.
It's an "experiment", which means it could be using some of the latest and cutting edge HTML5 specs. Chrome happens to be very good at supporting the latest specs. It's significantly more ahead than Firefox, and it's way, way, way ahead even than the latest version of IE.
So if an "experiment" meant to use the latest technologies happens to "only work in Chrome", don't blame Chrome for implementing the specs much faster than anyone else, and then developers taking advantage of them. Blame IE and others for not implementing HTML5 specs fast enough.
Unlike in the IE6 age where Microsoft did not follow the HTML standards, and made up their own new technologies, other browsers couldn't have implemented them even if they wanted to. In this case, if IE can't play this experiment, it just means it will be able to play it after one or two other major releases, once they get off their asses and get around to supporting the specs Chrome is support today. It doesn't mean they will never be able to support them (again, unlike with IE's tech in the "IE6 age").
> It's an "experiment", which means it could be using some of the latest and cutting edge HTML5 specs.
That's fair.
> Chrome happens to be very good at supporting the latest specs. It's significantly more ahead than Firefox, and it's way, way, way ahead even than the latest version of IE.
That's not accurate. Chrome is ahead in some areas, but behind in others.
But the bigger point is that the site says
> "We're sorry, but World Wide Maze is an experiment that was designed with the browser Google Chrome in mind."
If it said "with modern HTML5 in mind", that would be fine. But it says it was designed for Chrome, not for standards.
>Chrome is ahead in some areas, but behind in others.
Correct, but as a whole, it's significantly more ahead than Firefox, and it's way, way, way ahead than even the latest version of IE. What you said doesn't contradict that point.
I don't agree that it is "significantly more ahead than Firefox" - can you back that up? There is a long list of features that each of those browsers has, that the other does not.
As for IE, I don't run Windows, so I know less about it.
* CSS 3D is still very buggy (http://acko.net/#force3d) despite the support being over a year old now. Also renders without anti-aliasing, which makes it really ugly.
* Both Firebug and the built-in inspector seriously lack compared to Chrome's dev tools which has a per-frame timeline, profiler, etc. Instead they added the rather pointless 3D tilt view of the DOM which doesn't show you the actual DOM layers (unlike this 5 minute CSS 3D hack: http://www.youtube.com/watch?v=2-oQj9Y9I6I) and hence is just a misleading gimmick.
* No in-browser code editing/saving
* No Web Audio API
* No desktop notifications
* No MP3, no AAC, no H.264 support (on OSX anyway), the three most common audio and video codecs.
* No date/time picker, no color picker, no number range field
Yeah, I know there are reasons behind this, but still, the picture is heavily skewed in Chrome's favor
As for IE... CSS 3D support is incomplete (no nesting), its dev tools are pretty crap, and they seem to be actively ignoring standards like WebGL and pushing their own spec for WebRTC.
Those are indeed features that are missing from Firefox, yes. Although several are already there in nightly builds (WebAudio, number range, for example).
As I said earlier, it is easy to compile such a list from the other direction, stuff Chrome is missing. A few off the top of my head:
Again, both Firefox and Chrome are ahead of each other in various ways. Deciding which is "overall" more ahead means which features you care about - do you care more about JS language features or HTML forms? WebAudio or Opus? etc. There is no clear winner.
* asm.js is not a standard and was only announced 2 weeks ago. Hardly a fair comparison.
* ES6 features? All disabled on FF19.
* OPUS codec? Who uses that? Which codecs to support is not part of any standard. Browsers are free to support what they want. But at the same time, not being able to play the most common audio and video formats seems like a far bigger issue.
The numbers there are highly arbitrary - some things have large subcategories and so a big final number, while huge features like WebGL have few subcategories and a small final number. The numbers there are just an arbitrary decision by, AFAICT, one person.
Edit: Also, that does not include JS features at all. The modern web isn't just HTML ;)
Playing http://theverge.com with my Android phone - the final path just before the end of the level reads "Why Andy Rubin and Android called it quits".
Couldn't agree more. Instead of promoting cross-browser web standards in a cooperative manner, they're pretending they couldn't support other browsers in a sad attempt to win more users. Not going to happen.
They create those demos to attract users to their browser - kind of defeats the purpose if you can run it using any browser. I actually downloaded mobile chrome on to run this - I usually run Firefox.
If your purpose is to attract users rather than advance the web, sure.
But they _claim_ that the purpose of these demos is to advance the web.
That's not to mention that claims like "only works in Chrome" when in fact it works elsewhere happen to be lies. I guess no one worries about that sort of thing nowadays...
I clicked through all their fine print links and the demo ran OK on Firefox nightly using the desktop only option. Admittedly that cuts out a good portion of the demo.
I would love to see some apps better integrated - basic stuff like calendar and todo (BTW check out http://drive.google.com/keep - it's a rival to Evernote)
That was solved and properly done tens of years ago on the palm. Why can't I have something at least as good right into the browser, synced with my google account??
(Edit: not the wrong place since you already do your mail with a browser... and keep your contacts... and your todos... just remove the middleman, the website, and put everything in the browser. My guess is end users might love that)
How do they get other web pages, given cross-domain constraints? Are they downloading the page on the server into a headless browser like Phantom JS, and then delivering the result to your browser to be manipulated using WebGL and Javascript?
I get that there are capabilities like drawWindow() to turn parts of the dom into raster images programmatically, but how doe they suck the web page into your browser in the first place, given cross domain constraints???
I actually think I got it, and it's less impressive than I thought. Check this Screenshot: http://snapplr.com/hb27 ...they're essentially rendering the entire site in a headless browser like Phantom JS on their server and taking a screenshot (i.e. basic stuff any intermediate javascript developer can do).
Next, they're manipulating a basic image with WebGL, etc.
...So this is NOT impressive because they have lost the dom, unlike Firefox Tilt which maintains knowledge of the DOM the entire time--for example you can continue to edit the web page as you're playing around with the rendering in 3D space. With this you could not do that.
Tilt is a firefox addon, which must be where they get access other domains. Without being a firefox add on (or Chrome Extension), I was imagining this Maze experiment rendering the dom of another site in a headless browser on their server, and then delivering the resulting HTML to your page with all the absolute and relative URL paths of images and files adjusted so that they would render on another domain. And then at this point, the WebGL stuff could happen, manipulating an actual dom.
That all said, there are a few things that happen in the game that suggest knowledge of the dom, such as the way the make text have a 3D bubble cloud style. Maybe they are in fact doing some analysis in a headless browser, aside from just making a simple screenshot. They also break up logical portions of the page. So maybe the find the coordinates and dimensions of these logical portions and then in webgl crop the large image of the page at these exact coordinates.
I'm sure someone else has done a more thorough analysis. Would love to know what anyone else finds here to figure out how they're doing what they're doing.
How are they aware of the DOM level though? Certain elements pop out, are you suggesting they just use path mapping? It would be easier to, along with the screenshot, send the DOM tree hierarchy with some coordinates no? Still kind of impressive, but true it's no Tilt.
Does anyone know if the websocket connection goes through the internet, or if there's anyway it can shortloop to using LAN if both devices are on the same network?
I got disconnected twice within 1 minute, so I'm guessing the former... That, and I suppose unless you literally give it the internal IP of a device, it can't really make any assumptions (i.e. it's meant to work over internet too).
The connect doesn't work for me. I tried using the TabSync method and by typing the code manually. It just keep saying "please enter the 6-digit code".
Does this try to do a direct connection? In my network, that probably wouldn't work because of our firewall. Or it might if the port it listens on is high enough.
No, it does not. It appears to be going back through googles systems as the in between. I was able to play it and I know for certain my pc and tablet have no direct connectivity
This is the most impressive "experiment" I have seen come out of Google in a long time. Hopefully others will start to take advantage of these new technologies and we will start seeing more things like this. +1 to Google. Pun intended.
Okay so before I even got to the actual experiment I was impressed that the music on the page only plays while you are currently viewing the page, so if you are on another tab the music stops! I want to know how to just do that!
I haven't looked at the source code but according to https://developer.mozilla.org/en-US/docs/DOM/Using_the_Page_..., you can simply register a onblur / onfocus event handler on the window object (this doesn't use the recent Page Visibility API, it's been possible for a long time)
It depends on your video card and drivers whether WebGL will be automatically enabled / supported. I had to go to chrome://flags and enable the
Override software rendering list Mac, Windows, Linux, Chrome OS, Android
Overrides the built-in software rendering list and enables GPU-acceleration on unsupported system configurations.
They've recreated Super Monkey Ball entirely inside the browser, with the option of using a device as a controller. Certainly an interesting concept for multiplayer gaming, imagine Chrome running on a Smart TV(Chrome OS TV?) and a couple of friends can hook up their mobiles as controllers, and play some casual party style games like Monkey Ball or Mario Party.