[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

----- "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.  _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.

> 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.

Of course, doing the whole package on the web using web tech would, and WebGL is one piece that helps enable that... we're already seeing much experimentation, and I hope that we'll see bigger middleware packages for gaming and for other uses soon.  And where things are slow, we'll fix them :-)

    - Vlad