In November last year I stated that it would only be a matter of time before it happened. Also in November Joel Webber, a Google engineer had the inspiration to port Quake II to HTML5 from Jake2–a Java port of Quake II–using Google Web Toolkit; the same toolkit used for writing Google Mail | Maps | Wave in Java and compiling into JavaScript. With the help of two other Google engineers (Ray Cromwell and Stefan Haustein) in “20% time”, it works! Just!
How Does It Work?
^aEURoeGWTQuake^aEUR took Jake2, and run it through Google’s Web Toolkit (a framework and compiler for writing web apps in Java) to convert it to a collection of HTML5 Canvas / Audio / Video and JavaScript. Jake2 however relies upon various Java interfaces that are not present directly in GWT or the browser, for example the networking, keyboard and file IO. Joel had to implement new mappings to get the Java code to correspond to browser technologies. For example Java uses asynchronous IO, but JavaScript is event driven (onkeyup, onkeydown etc.). ^aEURoeStefan Haustein contributed new JRE classes to implement Java NIO Buffers around WebGL’s new typed javascript arrays, as well as a GL renderer based around WebGL.^aEUR
WebGL is an experimental technology to bring 3D to browsers using OpenGL ES, a cut-down version of OpenGL designed for embedded uses (The iPhone uses OpenGL ES 2.0 for its 3D API for example). Both Firefox and WebKit/Chrome nightlies currently support WebGL, but it may be some time before this technology reaches a release-ready state (the specification is still in flux, a draft was issued in December 2009).
WebGL revolves around the HTML5 Canvas element, which provides a rendering context that can be drawn into using JavaScript so that web pages may render images on a per-pixel basis. Canvas was originally invented by Apple for use in the widgets in the Dashboard feature as part of Mac OS X Tiger. The Canvas element has since been adopted and standardised by the HTML5 working group. Firefox, Safari, Chrome and Opera all support the Canvas element. It is not yet known if IE9 will support Canvas, despite committing to support for other HTML5 technologies like Video and Audio.
Another interesting HTML5 technology used is WebSockets. This gives the browser the ability to open a two-way TCP connection to a server for a communication channel. This is an improvement over AJAX, which is a synchronous request-response technology that has high latency, and much more robust than ^aEUR~Comet’, a hack to make AJAX behave more asynchronously. By using WebSockets, the web browser has the ability to channel data back and forth at high speeds and act more like a native application. In this case, GWTQuake uses WebSockets to provide networking between client and server so that GWTQuake can even be played multi-player! WebSockets, like WebGL are currently only supported on nightly versions of Safari/Chrome and Firefox.
Loading and saving of games in GWTQuake is done using HTML5’s Local Storage, it’s a key:value store for web apps to hold more data than what can be fitted into cookies. Google use this in their Mobile GMail web app for caching and offline access to data. Unlike cookies, the data is not sent to the server on each request and it persists after cookies are cleared. Therefore you don’t have to download or upload files to load and save your games in GWTQuake, you just open the URL and choose load from the menu!
How Can I Play It?
At the moment GWTQuake is only available by downloading and compiling the source code from the GWTQuake Google Code project site. Both the OGG Vorbis tools and Lame are required to convert the Quake2 data into OGG Video and MP3 audio for use in the browser.
There are numerous issues, depending on what platform you are, but I managed to cobble together the following instructions for Mac OS X from comments from others on Google’s instructions.
-
Install HomeBrew, to get Vorbis and Lame (and Mercurial) easily:
(Credit for these instructions goes to ^aEURoe64.brian^aEUR)sudo chown -R $USER /usr/local curl -Lsf http://github.com/mxcl/homebrew/tarball/master | tar xvz -C/usr/local --strip 1 brew install vorbis-tools brew install lame #if you don’t have Mercurial, brew install pip && pip install mercurial -
Checkout the GWTQuake source (requires Mercurial):
hg clone https://quake2-gwt-port.googlecode.com/hg/ quake2-gwt-portYou may need to ^aEURoecd^aEUR into the quake2-gwt-port directory now.
-
Maven runs out of memory compiling on OS X, fix this by using this command:
(Credit for this instruction goes to ^aEURoeredchris^aEUR)export MAVEN_OPTS=-Xmx512m -
Compile, download the Quake2 demo, and run the server:
./build-dedicated-server ./install-resources cp -r maven-build/server/target/gwtquake/war/gwtquake war ./run-dedicated-server 8080 -
Play the game by opening http://localhost:8080/GwtQuake.html in your browser!
Browser Compatibility
At this moment, GWTQuake will only work on a nightly version of WebKit or Chromium. Sorry, no Firefox support yet. Apparently it is missing some feature that is required (I know that Firefox supports WebGL, WebSockets and everything required in theory here, so I wouldn’t know precisely why it doesn’t work without debugging it myself).
Google’s browser compatibility page provides download links for WebKit, Chrome, and what command to run to enable WebGL (which is off by default in both browsers).
Additionally, Chrome has to be run without the sandboxing otherwise it is very slow due to time wasted copying the framebuffer between processes.
Another major issue is that on most screens the game appears very dark. This is because the original game did gamma adjustment on the textures as it loaded them and this was not ported as such to GWTQuake for efficiency reasons (see the FAQ page).
For the screenshots I’ve included in this article, I’ve forced my screen’s gamma to be 1.2 so that the screenshots are more visible.
How Does It Play?
Surprisingly well, considering it’s in a web browser! There are a number of bugs. When I loaded the game, there’s just a black screen in Chrome, and the console text overprints itself. Just press enter to bring up the game menu.
One rather cool aspect of the web-ness of the code is that the data loads asynchronously. As you start a game, the textures load into view much like images in a regular web page!
In WebKit, I found that the objects in the game (gun / enemies / other interactive objects) flickered. In Chrome I didn’t get any sound, but the flickering was gone.
In WebKit it was reporting about 7-10 FPS, though to be honest it felt significantly smoother than that (nearer to 20 FPS maybe). In Chrome, I was only seeing 1^aEUR“2 FPS. Ray Cromwell reports that ^aEURoeOn WebKit/Chrome I can get 20-25fps on a MacBook, and on my Mac Pro desktop, I get about 45fps. Joel reports that a Linux notebook gets up to 60fps^aEUR.
Aiming can be sent a bit skewiff if your mouse pointer falls out of the browser window, so full screen is a must if you have any intention of playing properly.
Of course it should be understood that this is a) highly experimental, and b) highly-unoptimised. The FAQ page notes that:
The original Quake II code was straight C, written in the mid-90’s. The Jake2 port to Java was very direct, which preserved most of it’s C-isms, including giant bags of static methods where C functions used to be. In addition to this, we hacked and slashed our way through the code to get it going and reasonably optimized, but there was definitely some collateral damage along the way.
Considering that it was compiled from hardly ideal Java into JavaScript, it’s still impressive performance. If the game were written from scratch straight into JavaScript (or even better, using Native Client), I suspect that performance would be much better.
What Does This Mean?
It means that you should not assume that the web browser is just a document viewer, nor is it as slow as it used to be, and nor is it as incapable as it used to be.
However, none of the technologies in use here having left draft status. I would put it at around two years before this technology (and games using it) arrive in the hands of the public via mainstream releases of Safari, Chrome and Firefox. But those innovating will be ready to hit the ground running.
What this means for users in the long term is a great simplification and removal of many hurdles for users. This is a 3D game that you can play just by visiting a URL. No installation, nothing to download and install. You ^aEURoeinstall^aEUR the game by bookmarking it. As simple as that. URLs could even be constructed to point to specific rooms in multiplayer sessions, so that you could invite someone into a game in progress just by sending a URL through e-mail, IM or twitter and such!
There’s been a lot of debate about HTML5 vs. Flash, especially with the imminent release of the iPad (which despite complaints from some doesn’t seem to be having a problem getting some major users of Flash to jump ship to HTML5). Whilst HTML5 cannot fully replace Flash yet, the features are coming, and those features will even surpass what Flash can do. Mozilla have demoed WebGL running on a Nokia 900; they decided to disable Flash by default on Firefox Mobile stating ^aEURoeThe Adobe Flash plugin used on many sites degraded the performance of the browser to the point where it didn’t meet our standards.^aEUR
Adobe have promised that Flash 10.1 will increase performance, but this won’t change the fact that neither the iPhone, nor the iPad include Flash. Once a web developer writes content in a standards based way to work on the iPhone / iPad, why would they choose not to serve the exact same content to desktop users, and redo it all again in Flash?
Quake II in HTML5 does not exist to somehow be a practical example of the technology. It is to inspire developers to push the boundaries of what’s assumed what browsers are capable of. Compelling, graphical games and experiences can be delivered to users with nothing more than a URL, with all the freedoms of distribution the web offers (compared to the App Store for example), across multiple OSes and multiple platforms and processors. It will take many years for the availability of this technology to trickle down to devices everywhere, and many more years for the development tools to become readily available to all levels of skill; but come they will, because the Internet is the new operating system.
That’s a lot of new stuff that hasn’t been vetted by security gurus. A lot of new attack surface, that’s more closely integrated with the host.
Its cool, yes, but it makes me shiver to think of all of the security implications.
And you^aEURTMd rather Apple choose which Apps are ^aEURoesecure^aEUR and which ones are not?
I^aEURTMd rather have all this stuff in the open where anybody can prod and poke it and _find_ and _reveal_ the real security holes.
BTW, the recent Firefox security flaw (for which 3.6.2 was issued) was because of a lack of security testing on the font library that was pulled in, that was never designed to handle files randomly coming off the web; so the concern is definitely legitimate, but then Mozilla let that slip because of weak security testing of a new component and hopefully they will learn from that.
Oh,Hell no. I want that like I want a kick to the groin.
Just hoping that this stuff is being reviewed by security researchers at the design phase.
I think we’ve seen enough evidence that these reviews don’t stand the test of time. It might get passed now but for sure there’ll be some form of security breach with any complex technology and this is certainly going to be very complex.
Any thoughts of security in the design phase of a spec, are better than none. Nothing is perfect, but that doesn’t stop anyone from doing their best.
Aha ! The same bullshit argument saying that because everybody can see the code, it’s more safe.
I have a news for you, as everybody can see the code, it’s also easier for a bad hacker to find security holes and don’t tell anybody about what he found…
Anybody can see the code on a closed source application, also.
It’s not like ‘binary’ is this mystical mush that is undescipherable to human-like.
Machine code, like source code… is just that: code. Removing access to the human-written source code makes things more difficult, but it does not make it even remotely impossible or impractical to find flaws in it.
It just makes it impossible and impractical to fix problems that get found unless your the original developer.
Just look at the most popular ways people’s computers are hacked. Internet Explorer, Adobe Flash, Adobe Reader, etc etc… Not having the source code has not slowed anybody down much when it comes to “owning” your computer.
Yeah and you can say the same for Linux. Just as the last big security holes which was present on all linux kernel from 2.4 to 2.6 all releases …
It wasn’t faster to find the security hole which has been there since many years.
And it’s much easier to read source code than binary.
If you say the contrary:
1. you are in bad fait
2. then prove it and stop using high level languages (C, C++, Python etc …) to make your software …
Just as the last big security holes which was present on all linux kernel from 2.4 to 2.6 all releases …
All OSes have bugs, you know? There is not a SINGLE OS on the whole planet without a bug somewhere. And besides, Windows too has quite big bugs there but being closed source has not stopped anyone from finding them; quite the contrary, it only stops people from patching them.
There is actually a bugfree OS. I dont remember the name of the company that created it but I think it was australian. They mathematically verified it to be bugfree. It can be done by using special language semantics that makes it side-effect free (it basically means that given a set of input it will always reply with the same output). Functional programming languages like Standard ML and Haskell are very good at that.
And that is the thing; with more testing, more stress testing of technologies – hopefully the weaknesses are exposed early so they can be addressed. Take ActiveX, by itself, it is a great piece of technology but it took at least 10 years before Microsoft finally locked down ActiveX.
Oh dear Lord, did you just say active X *is* great? As the creator of many active X controls, I’d have to disagree. It *was* the best solution, when you were dealing with a MS only environment in the late 90’s early 00’s, but its dead Jim. And, I really think Microsoft could have done something better. It really didn’t become secure, until it was obsolete because the priority of security at microsoft didn’t really exist until 2004 or so.
Javascript also isn’t highly valued by web developers.
But it does a good job of showing the potential of HTML5.
I suppose Native Client will help those who don^aEURTMt want to provide the source. It^aEURTMll be faster to boot too; I can^aEURTMt see it getting adoption outside of Chrome though. The last thing Apple wants is native code being delivered outside of the App Store.
Server-side processing with output to HTML5 would do the trick. This also means that the game engine wouldn’t have to be coded in javascript.
Developers would flock to such a framework because it would be cross-platform and insulted from piracy.
Or even better, cgi or .net on server side with H.264 output.
edit:
It’s not good to run code on the server: imagine what if some 100 000 users want to play same time?
The best way is using java or silverlight.
Edited 2010-04-02 18:01 UTC
I think a mix is probably the best, have a client to share some of the processing but make it useless to pirate.
But if we’re talking about replacing 2D iphone games a single dedicated server can handle plenty of players.
So hypothetically speaking when it comes to native code, Microsoft could have a native code back end for Microsoft Office and then the output would appear as HTML5? I remember hearing about COM support being added to Silverlight – is that the possible future, the front end being delivered to the end user via Silverlight with the native processing occurring on a server farm at Microsoft HQ?
It’s hard to tell if your all being sarcastic or just being ignorant.
Microsoft has exposed the COM to expose ‘native code’ to the internet.
It’s called ActiveX and it sucks huge donkey dick. It’s just a really bad idea and causes all sorts of horrificly bad things to go on in the web.
I am sure that Chrome’s ‘native code’ is not as horrible as ActiveX (as Google engineers are not huge f-ng morons like the ActiveX architects were), but there is no need to do anything like that.
ECMAscript is ugly and it’s not fun, but it’s a complete programming language that is just about as capable as any other high-level programming language anybody would care to embed in the browser.
It’s now relatively fast with modern JIT compiling technics and whatnot and it’s been around, in one form or another, for decades now and is supported and used by not only browsers, but a ton of different applications.
so that is why that if people had a chance to do it all over they would choose something else ecmascript is still a win for web-based applications.
That is a likely future but I doubt they would use COM. They’d probably rewrite large parts of the office engine to run on the server and then build the interface in Silverlight. It would likely be a subscription service as well.
Edited 2010-04-03 19:22 UTC
“Javascript also isn’t highly valued by web developers.”
That is so true. I think the issue is the level of understanding amongst web developers of what JavaScript can really do. Most don’t think past DHTML.
I has taken me over 10 years of professional web development to realise how powerful JavaScript can really be.
A lot of it has been because that as web developers, we develop around the idea that web users can disable JavaScript within their browsers. The thinking has been why put effort into something you can’t control?
But finally, I think, we are coming to a point where the lowest common denominator is no longer our target demographic. Viva La Web!
That is completely true, and it is also a crying shame. Modern versions of Javascript are quite powerful and there is more work being put into optimizing performance for them than virtually any other interpreted language. Most developers never see past the basic DOM model and don’t really delve into the language itself – they just use it as a tool for doing DOM manipulation and thats it, more or less treating it like a macro language.
I’m not claiming it is the most beautiful language ever designed, but it does have most if not all the features needed to write code using virtually any programming paradigm you can think of (OO, procedural, functional, event driven, etc.)
I personally prefer Python, but I would have to concede that for its intended purpose Javascript is probably a better language. I have always been curious if a Python implementation of a browser scripting language could be competitive performance-wise, but from what I have seen I highly doubt it. Python is beautiful, but Javascript is practical (and fast relatively speaking).
Really man? Might want to check that twice. I’m a Web Developer, and I value Javascript highly.
The original article was posted on April 1st. Anyone verified its authenticity?
Because i would hate to think that this site was regurgitating april fools cranks on april 2nd (3rd here in aus)
I really dont want to have to write off this site for the whole week from my calendar next year.
Er, the video, the screenshots (which I took), and the compilation instructions, including link to the Google code site with the full source code isn^aEURTMt good enough?
I mean, porting Quake II to HTML5 for real, for an April fools joke is pretty high on the effort-required scale for just a prank. Anyway, the article said that this has been under development since November last year.
If you haven’t seen it:
The story at
http://timepedia.blogspot.com/2010/04/gwtquake-taking-web-to-next-l…
was written on the April, 1st.
And the sourcecode at
http://code.google.com/p/quake2-gwt-port/source/browse/
was completly cheched in on April, 1st.
And later comes nothing.
Not only that it is annoyed, to read on 1st April all the April fools.
Additional there are on the 2nd April and after it “news”, which cite old April fools, which the new writer haven’t realized as April fool.
I^aEURTMVE PLAYED THE GAME. IN MY BROWSER. I COMPILED THE THING FROM SOURCE AND UPLOADED SCREENSHOTS.
What more proof do you want! You can go compile and play it yourself.
The reason the whole code was checked in yesterday was because it^aEURTMs a public site, duh, and they wanted to hold back and not let anybody find out until they were ready.
I’ve made a HD video of the thing…
http://www.youtube.com/watch?v=OZR_m8pBYcU
It’s not a joke.
Anybody else wish you could run Python in a web browser?
There are people wanting to get javascript on the server…. I think it would be better to get PHP or Python in the web browser.
I don’t think so, but I wish we can run native x86 in the web browser.
Though being realistic I have to be pleased that at least I can run .net in the web browser.
Native Client http://code.google.com/p/nativeclient/
I don’t think so, but I wish we can run native x86 in the web browser.
And lock out all non-x86 platforms, including the millions of different portable devices both those that exist already and those that will come? Wow, sounds like an excellent plan. Oh, wait..
That’s why I wish we could run LLVM in the browser
Heh, just wait, someone will implement that too sooner or later!
Already being done. Portable Native Client uses LLVM bytecode:
http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf
That will be awesome.
We are getting closer to what I have always believed was an inevitability – where stuff resides shouldn’t matter to users or developers (ignoring security for the moment!).
What do I mean?
Well, a long time ago, and far, far away, the CD-ROM was a new technology. It was a big deal for programs to be able to access information from this medium. They were “multimedia aware” applications. Standards were written. As Biden would say, it was a BFD. You had to specifically code your application to be able to access the data on this mystical storage medium.
Presently, the CD-ROM is just one of many removeable media. Entire operating systems can run off of one. It’s no longer a BFD. I’ve always felt this would one day be true of the Web. Java brought some of this, where Applets could access data just by URL’s. Web Services have brought us closer, as has AJAX. Web 2.0 if a BFD.
Soon, though, data will just live where it lives. Applications will run from wherever. And the developer and the end user will not even think about. It will no longer be a BFD.
So, besides health care reform, what’s the next BFD for computing? I’m thinking maybe OpenDOC…
Thin clients, of course. Duh!
Reminds me, the other day I saw a guy taking notes with a hand-held lead device on a flattened, wood by-product. He was able to easily combine graphics and text, consumed very little power (totally wireless), and utilized persistent storage. I was amazed.
Did he use a graphite-based stylus or a petroleum-based one?
I think it was graphite, and it had the backspace key on the top of the stylus.
But seriously, I am a Computer Science student (over 50) with several laptops, including a netbook. Nevertheless, due to the small desks, and the mixture of symbols in the notes (e,g, calculus), I have found a good mechanical pencil and a notepad to be the best note-taking device.
However, if Apple want to send me an iPad (like they do the editors, here), I would be willing to try in out in class!
What technologies are you talking about? WebGL? HTML 5?
I think that the porting of Quake 2 to javascript is just a show-off, a proof of concept. I don’t really think that Google engineers consider javascript the way to go for web games.
Any kid who even doesn’t finished the most elementary IT class yet, knows that javascript is a interpreted language ans as such, it sucks badly in terms of performance. Even worse, it’s interpreted by a web browser, a software not known for it’s remarkable focus on performance. Trying to write a game in javascript, if not done as a proof of concept, is as stupid as trying to write a game in bash.
There are far better technologies such as java and silverlight.
So, you^aEURTMve done how much work with JavaScript?
1. Performance of JS has increased 1000 fold in the last two years. It can be as fast as 50% native speed in some cases.
2. ^aEURoeTry writing a game in JavaScript”. Glad you said that, because I have. Multiple times. And guess what? It^aEURTMs plenty fast enough. I don^aEURTMt have anything finished enough to show, but here^aEURTMs something better than I can do as an example: http://www.megidish.net/awjs/
Java is dead. Silverlight will follow eventually, for the same reasons as Flash. Not everything will support it and HTML5 will allow developers to target everything in one go.
EDIT. Forget my gumpf, have you realised the idiocy of saying that JavaScript isn^aEURTMt fast enough for games, when you^aEURTMre commenting on a thread ABOUT QUAKE 2 RUNNING ENTIRELY IN JAVASCRIPT. Good grief.
Edited 2010-04-02 18:06 UTC
I was talking about real games such as Crysis, Assassin’s Creed, Dragon Age, Grand Theft Auto and so on. Not about the next breathtaking Tic Tac Toe, Tetris and Hangman.
Java is not dead, that is just wishfull thinking on your behalf. Tell that java is dead to millions of companies and individuals who are developing and using java software. Silverlight is near anywhere as dead. Silverlight is just at the beginning.
I was talking about 2010 games, sorry if smart people like you consider idiotic anything that is less than 15 years old.
I was talking about real games such as Crysis, Assassin’s Creed, Dragon Age, Grand Theft Auto and so on. Not about the next breathtaking Tic Tac Toe, Tetris and Hangman.
No one would write those in Java or Silverlight either, so your point is quite moot.
No one cared to write them in Java or Silverlight, but Java and Silverlight are much reasonable game platforms than javascript. At least since some professional games are/were written in .net, why can’t they be written using Silverlight API? Add some DirectX bindings to SIlverlight, and voila, you’re on your way.
What do you mean by “professional games”? People are paid to write games with JME, are they “professional games” as well?
No one cared to write them in Java or Silverlight, but Java and Silverlight are much reasonable game platforms than javascript. At least since some professional games are/were written in .net, why can’t they be written using Silverlight API? Add some DirectX bindings to SIlverlight, and voila, you’re on your way.
Both Java and Silverlight were designed with being overall more capable than Javascript but Javascript has been closing the gap very fast lately, and I am sorry but I just have to disagree with you.
And what has .net to do with the discussion? Does those “professional” games run in the browser across several different platforms? No? Then they have no place in this discussion.
Ummm… no?
JavaScript still sorely lacks a type system – which in turn limits the IDE’s (many IDE features depend on type information being present). Also, the available libraries are nowhere near what’s available for Java (not sure about Silverlight).
EcmaScript 4 had a lot of promise, but sadly got side-tracked…
Edited 2010-04-02 22:52 UTC
Well the framework isn’t there yet to build those games so your point is moot as well.
When that framework is available it won’t be HTML5. It will be a proprietary plug-in like Silverlight that offers more than client side Javascript.
And I^aEURTMm talking about real games like Bejewelled and Farmville that have more users than those games and make just as big bucks.
Java is dead for gaming, like we were discussing, ne?
I thought we were discussing JavaScript being fast enough for games, which it is. I^aEURTMll grant you that there aren^aEURTMt many games written in JavaScript because _so many developers are still hung up on IE_. But it^aEURTMs not that it isn^aEURTMt possible^aEUR”and Quake II in HTML5 should raise eyebrows and get interest going in developing games in the browser, which I^aEURTMve known has been possible since Firefox 3.
It has nothing to do with IE. Flash and Silverlight provide a better framework for games and that would be true even if IE didn’t exist. HTML5 will improve but so will Flash and Silverlight.
But Flash and Silverlight will never be on the iPad, and like it or hate it, the commercial world so, so badly wants a bit of that pie.
I think the commercial world will be sticking with the itunes store for the next few years. Cross-browser compatibility isn’t everything.
But it will be interesting to see the HTML5 apps that hobby developers create. Just don’t expect a web app revolution like so many claimed would happen with Ruby on Rails.
Oh, and no one told me nothing about it
http://www.runescape.com/
http://www.nordgame.com/
http://www.banghowdy.com/
http://www.gamerendering.com/Imperii/
http://www.madskillsmotocross.com/
http://ghook.speedrungames.com/
not to name all the games being developed for J2ME, Android, and all the studios now using Java/JOGL for their tools.
I concede, I’m wrong, I had forgotten Android development!
Flash has been the mainstay for cross platform gaming for a few years, and I have every reason to believe a big battle for the gaming space is now brewing. Apple are cutting off Flash in favour of Cocoa. Adobe are trying to push Flash on mobile devices. Java will always be there, as it basically always has been. Microsoft are trying to build a new lock in ecosystem with Silverlight / .NET / XNA / DirectX after their old lock in IE failed, and HTML5 will be aggravate the lot of them in the long run.
Edit: Oh^aEUR”and Nintendo are seeing the first serious competition in the mobile space they^aEURTMve seen in ages. The iPhone may only represent a tangential threat to Nintendo^aEURTMs market, but it has definitely lowered the price consumers expect for a game.
Edited 2010-04-02 21:10 UTC
You forgot the best www-browser based java game ever made.
Minecraft:
http://minecraft.net/
I really want HTML5 to succeed, but to be honest people have been doing games in activex/directx in IE for over 10 years. I think someone created some extensions for flash to do the same with directx as well, can’t remember. You can load compiled VB or C (not the VBscript-kind) in IE through .htc-behaviours as well.
But it’s all proprietary.
It’s W3C which is slow, even Mozilla had a proposal for XBL-behaviours which didn’t get accepted, I’m really glad we are making progress now though.
It’s not entirely running in the browser, it’s running on the server, like gmail. Just everything that is needed to get the visual part to the browser has been done. Just have a good look at what Google Web toolkit really does. It offloads as little as possible to the browser.
EDIT: typos
Edited 2010-04-04 10:28 UTC
They compiled the one-player mission statically. No server computation involved.
Ohh, ok, my misunderstanding I guess, but I still wonder why then run it on localhost:8080 ? Why not just dump the static code in a directory and serve it from a any webserver ?
Edited 2010-04-04 10:36 UTC
The localhost:8080 thing is because you run the dedicated server to enable multiplayer and because Quake just runs like that. Nothing is ideal here because it^aEURTMs a C app that^aEURTMs been ported to Java and then transcoded into JavaScript. If you were writing a game in HTML5 from scratch you certainly wouldn^aEURTMt do it this way, and it could be written to run from a folder much easier
Javascript implementation can be interpreted of compiled (JITted). E.g. Chrome runs all javascript as native code.
It may be that the Canvas implementation is what’s slowing things down here. With opengl, this would probably be pretty snappy.
If you are willing to go for Silverlight, you could as well go all the way and make a normal, native Windows game.
I’m not willing to go for anything since I prefer native games and I think that every software should do only one thing and do it good: the browser should display web pages, the video player should play movies, the audio player should play music and the damn games should be native.
I was just pointing that if somebody wants games to run as web applications, there are much better choices than javascript which is not meant for games or anything that has to do with performance.
Of course natively compiled code is much faster compared to interpreted code. However, Java and Silverlight don’t contain natively compiled code either: their ‘binaries’ consist of bytecode that has to be run by a Virtual Machine, too.
Compiling source to bytecode beforehand might give Java and Silverlight a bit of a head-start, but after that the interpretation/JIT-compilation techniques are not all that different.
A difference is JavaScript is much more ‘dynamic’ than the typed Java/Silverlight code – the VM can leverage the typing information to perform optimalizations on Java/Silverlight, this is much harder with JavaScript
Why does everyone lump java in the same category as flash and silverlight?
Flash and silverlight are browser extensions.
Java is a full fledged virtual machine/language/api for making desktop applications as well as applications that can run in a browser. What silverlight and flash do is only a small subset of what java does.
Edited 2010-04-03 00:20 UTC
Indeed Java is more powerful than Flash/AIR.
But when Java applets and JavaFX are entering the ‘web applications’ arena, they will have to compete with Flash and Silverlight, and a comparison is justified. Java has an advantage for being such a full-fledged platform, but this also comes with a cost (e.g. slow start-up times).
That said, Java and Flash/ActionScript are not really in the same ballpark in terms of language maturity and availability of libraries. I’m not so sure about Silverlight: doesn’t that allow you to talk to any .Net code? That would make it quite similar to Java.
Several big stock exchanges with ultra low latency and extreme performance demands are developed on Java. Java is foremost for the server, and then for the client.
No argument there – for example slow start-up times are no problem in such situations, it’s throughput and fail-safety that matters. The browser/client arena is simply a whole different ballpark.
nice troll.
What the hell is going on. Can someone just take a step back and look at this and say. Wait a minute. What are we doing here. We started out with a browser that rendered html nicely. It was simple and had a well-defined purpose. Then we added javascript to stur things up a bit and then css and a bunch of more little things again and again and now we have a broowser that can play quake. Shit what should we add next? I know. Let’s add a f–king particle accelerator. Why? I don’t know. But it is coooool.
Completely agreed.
The WWW, The Big Regression in Computing, BRC.
Of course the cool kids here are delighted to see over ten year old crap being run in a browser. Kind of shows the current state of affairs.
And it is even funnier that all the Javascript, and Silverlight, and Flash crap comes over again. But no one questions that it is totally idiotic to put more and more crap to into WWW to begin with.
Totally. Do one thing and do it well as the saying go.
In my opinion this article just demonstrate the potency of HTML5.
I’m curious to know why you used Homebrew instead of Macports. Is it lighter or it’s just you couldn’t resist novelty?
Didn^aEURTMt want to mess up my filesystem. I^aEURTMm picky about installing stuff into the UNIX area that is too oversized and difficult to maintain and operate. Brew is just a folder and plays nicely with Apple^aEURTMs layout. MacPorts is a giant dump on your drive with it^aEURTMs own opinion on how to run the shop.
Fair enough. Also, I think you forgot to mention this is for Intel Macs only.
Get your development theories here:
Google Engineer suddenly ports Qukae II to web browser – get stuffed… This was a planned stunt. ChromeOS will be able to play games quite adequately through their OS. Much like OnLive
http://www.onlive.com/
The games etc will be hosted on their servers so no need to worry about security. Any documents and personal data that need to keep secure will keep on one server – data that does not have to be keep secure will be kept on another server (on one of the many gabillion servers).
You will not need to worry about a browser being insecure and data being accessed on your hard drive because the data will not be on your hard drive, it will be on Google’s.
Marketing hype that’s all this is… while being very cool at the same time