On Tue, Jan 26, 2010 at 11:08 AM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:

----- "Kripken" <kripkensteinr@gmail.com> wrote:
> Ok, back to the subject at hand: While we have some open solutions for 3D on the web like WebGL and O3D, they are not complete game engines. I don't think they are suitable for the kind of content I am talking about here (but please correct me if I am wrong!), which is games with full multiplayer support, physics and complicated world geometry, AI, etc., like FPS games and so forth. Some of that stuff might be added to WebGL and/or O3D using _javascript_. However, many games are too computationally intensive, even with the best _javascript_ engines out there. So, I believe that we need a native code game engine for the web, for the other intensive computations game engines need aside from rendering.

Not sure why you think that -- there are many games written in python, c#, etc., that do just fine.

I realize that, and in the Intensity Engine we use _javascript_ and Python as much as possible, and in fact most of the gameplay in our games is entirely in _javascript_. So I am entirely on your side in that respect.

However, our experience also showed us the limitations. While many or most games would work fine (exactly as you say), on the other hand a 'heavy' game like an FPS, that issues a great deal of rendering commands each frame, and does physics with large data structures (compressed octrees can take several megabytes in our games) - that ends up being too slow.

_javascript_ can and should compete well there. Though I think you're looking at WebGL backwards... it's not a matter of adding stuff to WebGL, it's about writing a game (or game engine) using web technologies, including using WebGL for rendering -- it's intended to be purely the rendering component of such an application/game.

Ok, I understand.

I was hoping though that there was some solution for computation-intensive games as well: WebGL doing the rendering obviously, and something else for the other stuff, and I thought this might be a proper place to ask. Sorry if it's offtopic.

> 1. Porting the Intensity Engine to be a web browser plugin. Perhaps to switch our rendering engine to O3D, and make a new web browser plugin of the combination of the two?
>
> 2. Another thought is to use Google Native Client (NaCl), porting the Intensity Engine code to that, and rendering through WebGL. Our existing rendering system uses OpenGL, so that seems to make initial sense. But I am not sure if there is a specific timeline for when NaCl will be ready for general use (I will ask on their mailing list). Also there is the question of how fast the connection between NaCl code and WebGL would be (a lot of OpenGL commands are issued each frame).

This is somewhat off topic, as this doesn't really relate to WebGL, but sure, porting your engine to be a plugin would be one way to get it to run in a browser. There are many disadvantages to that, some technical and some philosophical, and some purely mechanical -- it requires the user to download and install a plugin. Using NaCl might be another, as long as you are ok with a Chrome-only solution (at least for now -- don't think any of the other browser vendors have said anything about implementing NaCl or similar). I don't think either of those really solves the problem of getting the engine into the hands of users; a separate download with a standalone app would probably be simpler than either of those.

Yes, I agree with you, these options have serious disadvantages. That's why I am hoping to find a completely web-friendly solution here, or as much as possible.

- kripken

Re: [Public WebGL] 3D Game Platform for the Open Web?