[Public WebGL] 3D Game Platform for the Open Web?
Tue Jan 26 06:50:24 PST 2010
On Tue, Jan 26, 2010 at 11:08 AM, Vladimir Vukicevic
> ----- "Kripken" <[email protected]> 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
> 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.
much as possible, and in fact most of the gameplay in our games is entirely
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.
> 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl