3D Game Platform for the Open Web?
kripken
virtual worlds) platform. If we don't have such a thing, a proprietary
product may soon come to dominate that area, like what happened with
Flash for 2D interactive content and video. The Intensity Engine, a
project I have been working on for the last year and a half (and which
is built on top of a lot of previous open source code written by
others) is close to being a possible open source solution here: It
works, is stable, and has been in production for several months now,
successfully. It is currently a complete solution, except that it runs
outside of a browser. I am looking for feedback about both approaches
to 3D gaming on the web in general, and regarding the porting of the
Intensity Engine to be a browser plugin.
Note: I hope this is the right place to post this - after looking at
all the Mozilla lists, it seemed best, since the topic here is about
"Web innovations for the public benefit." I believe that the issue I
am raising is important for the open web, and one that I think might
be of interest to the Mozilla community in particular, given its focus
on open web technologies.
Ok, getting back to the the subject at hand: I would like to stress
again that this is *not* a vague proposal or some kind of vaporware:
The open source project I mentioned already works (just not inside web
browsers). To get an idea of what it can do, there are some videos and
screenshots on our website:
http://www.syntensity.com
http://www.syntensity.com/toplevel/screenshots/
You can also download and try it out for yourself from the download
page,
http://www.syntensity.com/toplevel/download/
We have binaries for Windows and a few Linux distros including Ubuntu,
and instructions for compiling it elsewhere (which is in general not
hard, and we can help you out if necessary on IRC or our forums). Here
is the code:
http://github.com/kripken/intensityengine
As the videos and screenshots show, this is a complete 3D game engine,
with full support for multiplayer networked games. We have already
made several games to show the capabilities of the technology: co-op
FPS, CTF, racing, platform, drawing, etc. - the variety is meant to
show that we are a general purpose 3D game engine, and not specific to
a particular game type. In fact the platform isn't aimed just at games
but virtual worlds as well.
As mentioned, the project is 100% open source. That includes all the
code: client, server, and master (metadata) server. The current
license is the AGPL, but that can be changed tomorrow if it makes more
sense to use another license (feedback about that is welcome).
So, to return to the reason I am posting now: I am very worried about
a proprietary technology becoming dominant in this area. While we have
some open solutions 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, which is games with full multiplayer support,
physics and complicated world geometry, etc. 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, for basically the same reason that O3D is written in C+
+ - that a complex rendering engine might be too slow in JavaScript -
we need in my opinion a native code game engine for the web, for the
other intensive computations game engines need aside from rendering.
My proposal is that the Intensity Engine can fulfill that role.
I am therefore asking for feedback about this topic in general, and
specifically about using the Intensity Engine for that purpose. To
make it relevant for the web, I am considering porting the Intensity
Engine to be a web browser plugin. It might also make sense to
converge with existing things, like maybe using O3D for rendering (and
the existing Intensity Engine code for everything else). Another
thought is to use Google Native Client (NaCl), porting our code to
that, and rendering through WebGL - but I am not sure if there is a
specific timeline for when NaCl will be ready for general use. Also a
concern is how fast it would be to issue a lot of OpenGL calls from
NaCl to WebGL, even if that is possible. So, all of these thoughts and
questions are things that I would really appreciate feedback on before
I actually start doing any work. Also, help is of course welcome.
In closing, here are some technical details about the Intensity
Engine:
* The core codebase consists of some 120,000 lines of code: 60,000 new
lines written by me, and 60,000 lines of code from Sauerbraten/Cube 2
(zlib licensed).
* The main engine is written in C++. Non-speed intensive code,
including plugins, is written in Python. Applications (games/worlds)
are written in JavaScript (which is run on Google V8; we also have
done some testing with SpiderMonkey).
* Uses SDL, MochiKit, Boost.Python and zlib.
* Games/worlds can be entered and played in (almost) immediately, just
like you can visit web pages with a web browser: No need to manually
download and install anything, instead the client (which you must have
previously installed) will download and set up the content
automatically for you.
* Both client and server-side scripting is utilized. This is done
using JavaScript, which lets you run untrusted content in a secure way
(again, much like when visiting a website).
* Physics can be run on both client and server, and you can customize
how the two interact.
* Custom API in JavaScript meant to simplify the creation of
multiplayer worlds (this aspect was the original inspiration for the
project). Uses a lot of the nice features of JavaScript. Also has a
lot of reusable code in the form of plugins: Game modes, entity
classes, objects, behaviors, weapons (for games that want such
things), etc. etc. The API was built to be extensible and adaptable.
For example, it would be fairly simple to add weapons to the racing
game (which currently doesn't have any), by using the appropriate
plugins and setting them up.
* Custom rendering engine using OpenGL (from Sauerbraten).
* In-world editing tools (also from Sauerbraten).
* Asset system, including dependencies and triggers, for organizing
content. Uses HTTP for the actual downloads.
* Networking is based on ENet/UDP (UDP is necessary for good
performance of position updates for fast-moving objects).
* Master server (which handles metadata and assets) written in Python/
Django. Includes a web interface to manage assets, see what servers
are running, etc.
* Automatic testing is used to prevent regressions.
* Cross-platform: Compiles and runs on Windows, Linux and OS X. Build
system uses CMake.
Thanks for reading this far, and thanks in advance for your input on
this matter. Aside from responding here, we also have an IRC channel,
#syntensity on FreeNode, so feel free to drop in there (I - kripken -
am also on #labs on Mozilla's IRC).
- Alon Zakai / kripken
P.S. "The Intensity Engine" is the technology, and "Syntensity" is a
particular website using that technology (that I run), basically a
serious test of the platform. We sometimes use the name
interchangeably, sorry about any possible confusion. The original idea
with the separate names was to keep it clear that the technology can
be used for other websites as well, not just for Syntensity.
Dan Mills
Interesting project! I think you should talk to the folks at the
WebGL mailing list:
That way you'll reach most of the key players driving 3D on the Web
(inside and outside of Mozilla). Also try the #gfx channel on Mozilla
IRC.
Dan
> --
> You received this message because you are subscribed to the Google Groups "mozilla-labs" group.
> To post to this group, send email to mozill...@googlegroups.com.
> To unsubscribe from this group, send email to mozilla-labs...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mozilla-labs?hl=en.
>
>
kripken
- kripken