Chrome World Wide Maze
chrome.com
chrome.com
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.
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!
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.
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.
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.
Isn't that the whole idea behind the WiiU?
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.
francois@playbrassmonkey.com
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?
Google want to connect your browser information with your phone information. And they're doing a good job.
* HTML5 accelerometer support
* Sync between mobile/desktop using websockets
* Web page slicing based (by the look of it) on DOM and image processing
* Battery
Lot's of it on my iPhone. But it's worth it :-)
This has since been acquired by Brass Monkey: http://playbrassmonkey.com/
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").
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.
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.
As for IE, I don't run Windows, so I know less about it.
Edit: Also, that does not include JS features at all. The modern web isn't just HTML ;)
* No CSS shaders
* 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.
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:
* A wide range of ES6 features, see http://kangax.github.com/es5-compat-table/es6/
* Proper fullscreen mode (resized)
* OPUS codec
* Microdata
* Scoped style
* asm.js
* etc.
All those are in Firefox.
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.
* 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.
* What's "proper fullscreen mode?"
Not all ES6 features are disabled? For example WeakMap.
OPUS would be used by more people if more browsers than Firefox supported it ;)
Proper fullscreen mode is fullscreen where the element has the right css, that makes it fill the screen as per the spec. Chrome does not do that yet.
It uses WebGL. Firefox has WebGL. This isn't really an excuse.
The only reason to only support Chrome is to advertise Chrome. This isn't a tech demo, it's an ad.
For me only a loading screen is shown.
Update: Found a video http://www.youtube.com/watch?v=7AvTl9aU5D8
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...
"This page is in Spanish; would you like to translate it?"
Other than that, it seems to be just stuck on the loading screen.
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)
(and now the kids have no idea what i'm talking about :)
Sometimes you have to actually play with something to appreciate its potential.
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???
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.
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).
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.
It does pick up on the smartphone movement on the minimap, but the ball wont move… I can jump tho.
Any ideas? (OSX 10.6.8, Chrome Version 25.0.1364.172 // iPhone 4 10.6.2, Chrome Version 25.0.1364.124)
edit - likely a webgl problem that I've brought upon myself by disabling the gpu-blacklist
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.
Option to get WebGL enabled by default