As a 3d hacker this could be really good news. Yes plugins suck. But... Widely adopted plugins do not suck. If enough people use this new plugin it could become "the way" to do 3d on the web.
He's providing both chicken and egg in the classic plugin paradox. I fear we will wait until rapture before Adobe hooks flash the GPU. I hope it works and I hope he publishes the api.
API? As far as I know the plugin is basically a port of Quake III into the browser window. I don't know what kind of API he could publish; this isn't Flash or Java.
I had an invite for the closed beta, went through all the steps to register and create an account, only to find they only supported Windows. What a waste of time.
I'm told they'll be support Mac and Linux eventually... but if your browser-based game requires yet another plugin to be installed, you've kinda missed the point imho.
Support for Mac is coming, I can't say too much other than that and I have no idea how long it will take them.
Do know this: almost all of the guys at id Software are Mac enthusiasts. Most of them prefer OSX over Windows, it's just that the current gaming market is still predominantly PCs.
There are also challenges with OSX that Apple hasn't made easy for game developers, so keep that in mind.
It uses a modified version of the id Tech 3 engine (which is written in C) loaded as a browser plugin.
The idea is that matchmaking is handled in the browser so that the game engine is lighter and only has to handle the actual playing of a game.
in addition, I'm pretty sure the novelty is that while yes, this could be done in a standalone .exe, the barrier of entry for anyone already surfing the web (i.e. everyone) is ridiculously low.
I would argue that getting someone to install a new browser plugin and restarting their browser (in my experience, people are very reluctant to restart their browser) is just as difficult as getting them to download a .exe.
I disagree. Browsers have their own package management. I click on the link for the plugin, say yes to a bunch of dialogs, the browser restarts, and now I have to play.
With a standalone program, more decisions are involved. I have to decide where it installs, and how I want to access that installation.
I recently packaged up a piece of software for distribution, and I would never have a ZIP file to unpack. It HAS to be a standalone setup.exe which installs to Program Files/program so nobody has to make a decision. Access is with an icon in the system menu. And there's an uninstall. It's made with NIS Edit, which is a great program.
I sell a downloadable program over the Internet, and so am fairly familiar with the notion of writing installers. (Note that this is a B2C program for highly non-technical users.)
Here's life:
a) Users will click past any screen you put in an installer, even if it comes with pre-checked options for reformatting their C:\ drive and shooting their dog.
b) Every additional screen in the installer costs successful installs, and hence conversions (if you're using free trials).
Accordingly, I don't ask users where to install to. I ask the system where program files is and it goes in the default directory there. Period. I don't ask them what to name the shortcuts in the start menu -- its named after the product. Period. I don't ask whether to drop an icon on the desktop, I do it. If they want to delete it they can hit a delete key as easily as unchecking a box, but it saves 100% of users another screen to process. etc, etc
But in this case they are doing it to play a kickass game for free. People download game demos all the time to play a game. People go to great lengths to play games for free.
Id is having a go at these people, plus all the others who can't be bothered to jump through any loop beyond clicking a link and ok-ing the browser plug-in installation.
oh, that is a valid point. I was more referring to post-install--e.g., once you install, you will be more likely to play an in-browser game than a standalone game, since you are (most likely) already surfing the web. And if games the caliber of Quake Live can be put into a browser, I say the future is here!
We originally partnered with another company and they wound up going out of business. We picked up all of the development work on that, and that was definitely a little bit of stumbling block and took us more resources than we expected.
That was the company I use to work for. Here's my comment I posted on HN from a few days ago on an article that did not get voted to home page:
#####
I'm particularly fond of Quake Live because a) I was heavy into competitive gaming back in the day and b) I dropped everything in my life and moved to California to work for the startup whose products influenced the creation of Quake Live. Assuming they still use the same technology stack, it's running on an Oracle DB and using Jabber and a few other common web languages at the transport & display layer. [There is a unique browser plugin to handle file distribution, and the game itself is a substantially polished version of Q3. There's no flash aside from maybe a few widgets.]
I say 'influenced' because the tech we sold id Software for QL has been significantly altered and re-written by their very talented team to fit their own ideas and intentions. [They picked up a few of our tech guys when the company shut down.]
The cool thing is based on my experience beta testing Quake Live since Dec. 07, a lot of design principles still seem to be intact. You can see screenshots of our first B2C gaming product from 06/07 here, you may notice a few similarities such as the queue system:
The company had to close its doors b/c we ran out of money among other things... however, it was one of the best learning experiences of my life and I have absolutely no regrets. Very happy to see that Quake Live has finally come to life!
#####
It's worth noting that we tried courting other studios to do the same with their old IP, but very few were interested. I think in retrospect we had some issues with packaging our technology to make it easy to use, but also a little ahead of our time. Furthermore, the gaming industry is so big now — it's like trying to be an actor in Hollywood. Without any street credit, it's extremely difficult to get a deal as a technology supplier and even harder to get funding. Selling our tech to id Software was a 'loss leader' that didn't pay off because, well, it took a lot longer to come to life than anyone was expecting.
When we were working on the product linked to above, the hardest part was having to 'bolt on' to other games without the original source code, and I believe that was a leading reason why the B2C product failed. We always wanted to make our own game to realize the vision of game+web, we just didn't have the money/resources to do it. That said, a leading reason the B2B tech offering failed was because it wasn't easy to use — it was tailored to our experience bolting on to games.
The outcome of it sucks for us, I wish we were still around but I couldn't be happier that id Software has been behind this as they are one of the few still supporting the hardcore FPS PC gamers (QuakeCon, etc..).
Also, for the techies... here's a PR we put out ~2 years ago that talks about our use of Oracle and multiplayer gaming. Jabber/XMPP became a big part later on.
A browser plugin that installs the engine, then it downloads the maps, config files, etc in browser. So I'd guess whatever Quake 3 was coded in, Quake Live is coded in.
He's providing both chicken and egg in the classic plugin paradox. I fear we will wait until rapture before Adobe hooks flash the GPU. I hope it works and I hope he publishes the api.