[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] 3D Game Platform for the Open Web?
On Tue, Jan 26, 2010 at 11:08 AM, Vladimir Vukicevic <email@example.com>
----- "Kripken" <firstname.lastname@example.org
> 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
many games are too computationally intensive, even with the best
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.
as much as possible, and in fact most of the gameplay in our games is
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.
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.
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,
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
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
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.