This week I wrote a post comparing O3D and WebGL.

Today I have finally spent some time playing with O3D and managed to implement some very simple applications.

Now that I have a clearer understanding of what O3D can and can’t do I have given some thought to the possibility of writing videogames in JavaScript. As I mentioned in my previous post I can’t see myself playing something like Fallout in a browser window. Nonetheless I can imagine simple multiplayer games, something like Monopoly or Risk, working this way.

I have developed quite a few JS applications that allowed users connected at the same time to interact with each other. It’s very simple, constant AJAX posts and gets with a server keeping the state of the interaction. Imagine something like GTalk integrated inside GMail.

This is all well and good when the interaction is limited to a few chat messages or coordinates of the mouse pointer on the screen, but multiplayer videogames have to shift a massive amount of data every second. When you play Gran Turismo online the position, speed and state of each player’s car must e synched across all the participants as often as possible. Add chat/voice data to that and you’ll soon realise that 30 players for one game calling your server at the same time to get and post data is just not manageable. Furthermore to ensure the timely delivery of the data to each client you are much better off pushing the data to the client rather than relying on it to call your server.

What O3D should add to its APIs is a DirectPlay alternative. Multiplayer support built straight into O3D. This way your JavaScript game will be able to establish peer-to-peer communication between all the clients without having to stress your servers. Simple socket communication giving the developers the ability to push data between all the peers connected.
Network support by being built inside the O3D plugin could also deal with all the annoying connectivity issues such as “punching” through NATs.

Without properly implemented network play I don’t think we’ll ever see 3D games flourish in your browser window.

Bookmark It

You may have read recently that Khronos is implementing something called WebGL. The objective of the project is to expose all of OpenGL ES calls to javascript. Thus allowing hardware accellerated 3d graphics within a browser.
Google has also been working on an alternative, called O3D.

Let’s first talk about the technical differencies between the two projects.

O3D and WebGL while both trying to bring accellerated 3D graphics to the web have taken two fairly different courses. As I mentioned in the introduction to this post WebGL’s plan is just to expose to JavaScript OpenGL ES 2.0 APIs. Whereas Google’s solution is based on a browser plugin.

If we think about this we’ll soon realise that WebGL depends entirely on JavaScript. JavaScript, as of today, is a fairly slow language. This point was made in a discussion thread on the O3D project website.

WebGL, being 100% dependent on JavaScript to do an application’s scene graph, is going to have serious problems drawing more than a few pieces of geometry at 60hz except in very special cases or on very fast machines. This means WebGL requires JavaScript to:

*) do all parent-child matrix calculations for a transform graph.

*) all culling calculations (bounding box to frustum or other)

*) all sorting calculations for dealing with transparent objects.

*) all animation calculations.

As an example the kitty demo in O3D is doing linear interpolations on 2710 floats to animate 170 transforms. The point is not that the artist that created the kitty should probably not have used 170 bones. Rather the point is it seems unlikely that JavaScript
will be able to do that anytime soon and if it can then just add more than one kitty to pass its limits.

Also we have to keep in mind that not all hardware supports OpenGL ES.

O3D, By virtue of being a browser plugin written in C++, so an additional (hopefully fast) abstraction layer on top of the GPU, allowed Google to define a new set of APIs to expose to JavaScript and keep us (the JavaScript developers) away from the hardware. O3D will take care of the interaction with either DirectX or OpenGL.

Furthermore Google has open-sourced O3D through its Google Code website. Which means we can all have a look at their code and participate in the project. This resulted in a lot of documentation being available. For a full overview of how O3D works check out the technical overview on the O3D project page.

Do you think that this is the making of a new “Standards war”? Both Google and Khronos are adamant that they are not competing. However I believe that ultimately only one project will come out as a standard. As the complexity of 3D web applications increases it is not feasible to write code for both “APIs”. The only question for me at this point is who will come out on top.

To answer this I would look at the audience of the two projects. OpenGL has been out in the wild for a long while and many developers of videogames, or general graphic application, are already familiar with the APIs and the way it works, therefore it would probably make sense for them to embrace WebGL.
Nonetheless O3D still stands a chance. For a very simple reason. It’s the web we’re talking about.

Frankly I can’t see myself playing a big videogame like fallout in a browser window anytime soon. These APIs will be used to enrich web application. Some examples are already coming out using O3D. Have a look at this Home Designer. Can’t you already see IKEA using it.
My point here is that we’re not likely to see game developers switch to the web. We’re much more likely to see web developers start working on games or application involving 3d graphics, and this is where Google wins.

O3D extends application JavaScript code with an API for 3D graphics. It uses standard JavaScript event processing and callback methods.

As a web developer I can keep writing JavaScript code as I’m used to without having to change the way I think to how a game developer does.

What do you think?

Bookmark It