I believe that the open web
needs a good open source 3D gaming (/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 the web.
Before getting into any details, 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, see the videos and screenshots on our website:http://www.syntensity.comhttp://www.syntensity.com/toplevel/screenshots/
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.
therefore asking for feedback about this topic in general, and
specifically about using the Intensity Engine for that purpose - it's
open source, and I believe it fulfills the necessary requirements (see
below for technical details about it). So, to make
it relevant for the web, I am considering some options:
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
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.
Ok, some more details about the Intensity Engine: You can also download and try it out for yourself from the download page,http://www.syntensity.com/toplevel/download/
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
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).
Some additional 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 (with some modifications) from
* The main engine is written in C++. Non-speed
intensive code, including plugins, is written in Python. Applications
* 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
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.
multiplayer worlds (this aspect was the original inspiration for the
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, view 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.
for reading this far, and thanks in advance for your input on this
- Alon Zakai / kripken
"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 names
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.