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.com
http://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 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.
I am 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:
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?
1.a. Alternatively, would it make sense to suggest contributing code
to O3D for this purpose? That is, to add multiplayer networking,
physics, etc., to O3D (adapting from our existing Intensity Engine
code)? Or is O3D focused just on rendering?
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).
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/
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).
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
Sauerbraten/Cube 2.
* 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.
* 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, 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.
Thanks for reading this far, and thanks in advance for your input on
this matter.
- 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 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.