Is the Web Ready for Compiled Code?

CPython compiled to JavaScript is now reasonably fast on Firefox 4 and Chrome. Startup takes a few seconds, but it could be done in a web worker, so as not to stall a loading page. Executing code afterwards is far slower than native CPython, but already fast enough to be useful for some things, and getting faster all the time. (There are other limitations, like importing of modules, but I'm mainly focusing on speed for now.) So, from the perspective of those two browsers, we might be able to use Python on the web.

However, for it to make sense in general, it needs to work well on all or almost all browsers people use. So, what's the situation with other browsers?

• The Python demo tends to run very slowly in older browsers, that don't have a modern JavaScript engine. But, those people will upgrade eventually, so this will be solved (except perhaps for a minority using IE6...).
• Currently Python will not run on Opera, due to a bug in their JS engine. They have been notified of the problem. As Opera has a quite fast JS engine, I am hopeful that compiled code will work there at some point.
• IE9 has a fast JS engine as well, but I don't have a Windows machine to test on. Has anyone tried to run the Python demo there? Update: Issue 22.
  
• Safari has had a fast JS engine for a while (these days perhaps not as fast as the other open source ones, given recent speedups in Firefox and Chrome, but still quite good). As in the previous point, I lack a machine to test on - has anyone tried there? Update: Works in Safari and even iPads.
  

Emscripten 0.7!

Main changes in this release:

• Lots of minor fixes and additions, in order to get CPython working. As a result there is now a web demo of Python, which seems to work quite well aside for being very slow in Chrome.
• Figuring out what to do with LLVM optimizations. It looks like all of them generate suitable code except for -instcombine, which apparently combines instructions in a CPU-specific way (so, it isn't portable, and confuses Emscripten). All the tests now pass with LLVM optimizations enabled (all but the problematic one just mentioned).

So, not much in the way of new features: As mentioned before, we are already pretty much feature complete at this point.

Python Demo

With help from rasjidw, there is now a web demo of Python. Check it out, and let me know if you find a bug!

The demo is of CPython, the original/standard Python implementation, compiled from C to JavaScript. What's cool about compiling CPython itself is that we get all the language features 'for free', both the common stuff you'd expect and think of first, and also things that if you were writing a new implementation, you might leave for last.

Known limitations:

• No import of modules - just the core language works. It should be possible to get imports working, of both C modules and Python ones, but it would require writing code for dynamic linking etc.
• I tested in Firefox 4 beta and Chrome 8, and for some reason the demo runs very slowly in Chrome 8 (perhaps related to V8 Issue 947?). Firefox 4 runs much faster but still obviously slower than native CPython. In any case that should improve once we get LLVM optimizations working.
  

A Ridiculously Recursive Bug

Work has been going on to get Emscripten to compile CPython (the standard implementation of Python) into JavaScript. It's very close to working, so I started to write an automatic test. But the test failed even though running the test manually worked.

That's weird, I thought.

Turns out that something quite amusing was happening. The automatic test system and other scripts are written in Python, and the test runner checks for script crashes and failures by scanning for the text that appears in a Python stack trace, which is to say something like 'Traceback (most recent call last)' etc.

Now, when Emscripten compiles Python itself, it generates JavaScript code that includes, unsurprisingly, all the constant strings in Python - including that very string! So the right output was erroneously detected as a failure.

I guess that's what can happen if your test compiles the very same runtime in which the test infrastructure is built... ;)

Lua Demo += Skywriter

The Lua demo now has a nicer interface using Skywriter, and some additional bugfixes under the hood.

Check it out, and let me know if you find any problems!

Lua Improvements

It seems there are people interested in running Lua on the web :) The Lua demo was on Hacker News, and some people noticed that certain things don't work - thanks for the feedback! - so I spent a few hours figuring out what was wrong. After some small fixes, the demo will now handle these statements:

• for k,v in pairs({'foo','bar'}) do print(k,v) end
• for x = 1,10 do print(x) end
• for k,v in pairs(_G) do print("->", k,v) end

which people mentioned did not work before.

The output seems ok, but I'm not totally sure that it's 100% correct, since my Lua skills are pretty rusty. That's also why I didn't notice the issues in the beginning - I saw that 'hello world' worked, and thought all was well ;)

If people really want to see this work properly, let me know about any other problems. I'm happy to work on it, I just can't do it without feedback since I don't know where to start testing. (Is there a standard test suite for Lua?)

The issues that had to be fixed in Emscripten were

• Lua uses varargs in ways that the existing code didn't support. So I improved that. Varargs are now emulated in a way that is basically identical to C.
  
• A few missing stdlib functions.

So, small stuff. In fact I'd be surprised if there were any big issues left, at this point, given the amount of code known to compile properly, but there are probably a lot of small things left to fix.

Emscripten 0.6!

Demo: Lua. Thanks to rasjidw and puffnfresh!

Other major changes since the last release:

• SAFE_HEAP checks for invalid reads/writes and nonportable LLVM bitcode. This is important as LLVM optimizations can lead to nonportable bitcode. We need to figure out which optimizations are at fault, so we can use the other optimizations - they should make us much faster.
  
• Much more optimized compilation of very large projects - both in terms of memory and speed. I am now able to compile Sauerbraten without the JS engine giving up ;) - still a very long way from getting it to run, though.

See the Changelog file for additional updates.

Worth mentioning...

First committed patch by someone other than me! Thanks puffnfresh :)

Now What?

For several months I've known that when I get home at night, I have tasks X and Y to do in Emscripten in order to move it forward. Last night, however, I took out the guitar instead. Suddenly, there is not much to do - basically the goals of the project have been achieved, Emscripten can compile things like the Bullet physics engine and run it on the web. As far as the core code-generating capabilities are concerned, Emscripten is pretty much complete.

So, what now?

• There are some additional optimizations and enhancements that can be done, like nativizing structures or emulating multithreaded code.
• There are various tooling improvements that can be done, like making it easier to glue together web code and compiled code.
• Emscripten could be used in other ways, for example, it could be combined with something like Rubinius that generates LLVM code from Ruby, allowing running Ruby code on the web.
• Various code cleanups and refactorings could be done.

I'm not in a rush to do any of these - none is urgent or essential. I guess I'll get around to them eventually, or perhaps someone else will.

Right now, I'm considering doing one or both of the following:

• Return to my original goal, that of bringing Syntensity to the web. In other words, to compile a version of Syntensity using Emscripten. The time of 3D-environments-on-the-web is almost upon us, and when it is, we need to make sure that the main tools for it are open source and platform agnostic. Sadly, currently the main contenders are not such.
  
• Some other side project, got at least two ideas in my head of things I'd like to hack up. They are very experimental and speculative though, so they may end up a waste of time. But if they succeed...

Bullet/WebGL Demo

Click on the screenshot for a live demo.

Emscripten 0.5!

Another Emscripten release has arrived, this time the focus was on building a large real-world library: Bullet Physics. For those unfamiliar with it, Bullet is an awesome physics library written in C++, which has been used in many places, including commercial games and movies.

Here is the demo for this release:

----------------------------------------------------------------------
Ran 168 tests in 1060.329s

OK

:P Just kidding, a real demo will follow. I'm working on something with Bullet and WebGL, but didn't want to delay the release for it.

About the work in this release: Bullet is much larger than other projects Emscripten was tested on before, and a large part of the work was to speed up the compiler. The result is that Emscripten now takes a reasonable amount of time - if it takes 10 minutes to build the Bullet C++ sources into LLVM bitcode, then it takes a similar amount of time to convert that into JavaScript using Emscripten (and it takes an even longer amount of time to run that through the Closure Compiler for additional optimization). So at this point there isn't much more reason to optimize for speed of compilation - it's in very good shape, fitting into the build process without slowing things down noticeably.

As expected, various small bugs were found while building Bullet, and a few additional tests were added to check for specific issues. There is also an automatic test for Bullet as a whole.

Overall, at this point Emscripten is capable of compiling large projects effectively; quite a lot of the original goals of this project have been achieved. Still lots of cool stuff left, though! More about plans for the near future in another blog post very soon.

Emscripten 0.4!

The focus of this release was on making the generated code faster. As the chart shows, we went from being 100X slower than hand-optimized JavaScript code, to around 5X slower. You can see the difference in the raytrace demo, which has been updated to use all the current optimizations.

5X slower is still slower. It will be hard to do much better, though, without either better JS engine support, or much more clever code analysis. Both will hopefully happen over time. Meanwhile, 5X slower is not too terrible, and there are some advantages over hand-written code - we hardly use garbage collection, so no GC pauses. Also, the speed really depends on the code - the comparison in the chart above uses benchmarks for which we have comparable code in both C++ and JavaScript. But the most interesting uses of Emscripten are to convert code for which we don't have a JavaScript equivalent. Also worth mentioning is that it is perfectly possible to hand-optimize the crucial parts of the code that Emscripten generates.

Some technical details about the optimizations implemented in this release:

• Use typed arrays, if available in the JS engine (thanks to pcwalton and njn for the idea)
  
• Optimize after the relooper runs, removing unneeded code flow overhead
• Nativize many more variables than before (i.e., move them off the emulated stack, and into native JS variables)
• Optimized stack emulation
• Inlining of various runtime code fragments
• Integration with the Closure Compiler: We generate output that it is very good at optimizing (thanks to Anders Riggelsen for the idea)
  

Also added in this release is support for the brand-new LLVM 2.8. That is now the version being tested against.

Emscripten 0.3!

Demo for this release: Raytracing. It isn't very fast, since the focus hasn't been on code speed yet, but it does show that a ray tracer written in C++, using SDL, can be emscriptened and run on the web.

So, I ended up doing more in this release than I had intended, causing it to take longer than planned. But it was for the best. Major changes include:

• Clang support: All tests now work in both llvm-gcc and Clang. The two produce somewhat different llvm bitcode, to the degree that different methods are needed with Clang, causing it to run 1/2 as fast as llvm-gcc code. That is mainly because llvm-gcc is more explicit with what it does, while Clang uses memcpy and such, with hardcoded C size values (4 bytes for an int, etc.).
  
  Emscripten therefore now supports optional 'C memory layout' (QUANTUM_SIZE in settings.js). For example, an array of ints of values 1,2,3 with that enabled is [1,0,0,0,2,0,0,0,3,0,0,0] (since each int is 4 bytes), and when it is disabled, [1,2,3]. The latter works fine with llvm-gcc-generated llvm bitcode. Note that things get even more complicated with structures here, which need to be aligned and so forth. Anyhow, after that effort Emscripten should now be able to support anything that C/C++ can throw at it.
  
  
• Faster compilation speed: The original goal of the release. Compilation speed is 2-3 times faster now. Still lots of room for improvement, but it isn't a major nuisance like it was.
  
  
• Proper memory management: A call stack is implemented, and static memory allocation (for global variables, etc.) is also possible. sbrk() is emulated as well, allowing dlmalloc, a popular malloc() implementation, to be emscriptened properly. In particular that lets you use a real malloc() in your emscriptened code.
  
  
• Much better native flow regeneration (the 'relooper'): A major challenge of translating LLVM to JavaScript is to implement native flow structures - if, while, for, etc. LLVM bitcode only provides chunks of code (I call them 'labels', but that's not the right name) and branchings between then. So Emscripten needs to figure out from that low-level data the high-level code flow patterns. Native flow structures are extremely important for good performance of the generated code.
  
  The first relooper worked on most tests, but was slow and buggy. I wrote a new version almost from scratch, and it now properly processes all the test code. It isn't very fast, though, I didn't focus on that. For that reason it is off by default, which means that Emscripten will not generate native flow structures (instead it will emulate code flow using a switch in a loop, which is very slow - but trivial to generate).
  
  
• The above-mentioned raytracing demo: For this, initial work was done on supporting SDL - just showing video data so far. The SDL Surface is implemented in JavaScript using a Canvas. I found this very amusing, to write C++ code with SDL, compile and run it natively using gcc, and be able to run that same unmodified code on the web through Emscripten ;)
  
  
• Lots more tests: There are now 37 separate tests, from small LLVM features to high-level tests like the CubeScript engine, dlmalloc, and raytracing; each test is run through both Clang and llvm-gcc, and with relooping&optimization both on and off, for a total of 148 tests. This takes 7 minutes on my slow laptop, which is starting to be significant, but it's extremely important in a project like this.

Next goals include performance of the generated code - lots, lots of low-hanging fruit there - and compiling yet more real-world code.

Emscripten, Now With More Clang

Emscripten can now work with Clang. It turns out that the llvm bitcode that Clang generates is slightly different from that of llvm-gcc, which uncovered various minor bugs and missing elements in Emscripten (for example, the 'phi' command).

All the tests now pass both llvm-gcc and Clang, and with both optimization and relooping on (however, relooping has been weakened, due to some bugs that were discovered).

The benefits of allowing Clang to be used is that having two sources of LLVM bitcode is better than one - more chances to catch bugs (but even more important would be to add non-C/C++ sources of LLVM bitcode as well!). Another benefit is that Clang is simpler to build so it will allow more people to play with Emscripten.

The wiki has been updated with full instructions, so you can get Clang and try it out with Emscripten right now.

CubeScript on the Web

Emscripten 0.2 is out, and here's a silly demo: the CubeScript engine from Sauerbraten, compiled from C++ to JavaScript, and running in a web page. Finally, you can use a script language on the web ;P

A few more details about the demo appear on that page. Other details about the 0.2 release are in the changelog.

After successfully compiling the CubeScript engine (which was mainly to see if Emscripten could do it - fixed a lot of bugs on the way), I think most C/C++ stuff should work (but there are probably a lot of minor corner cases left). The next steps are something like this:

• Version 0.3: Optimize the compiler for speed. Right now compiling CubeScript, about 2,500 lines of code, takes a minute on my (slow) laptop. The goal is to compile large projects, so this needs to be much faster.
• Version 0.4: Optimize the generated code for speed. Some radical solutions for making it faster are possible, but might take a lot of time, so maybe post-1.0. But some straightforward optimizations should be done in the near future.
  
• Version 0.5: Tools and integration. Make it easy to build multi-file projects, and to connect the generated code to web JavaScript (calling functions both ways).
• ???
• 1.0!
  

Emscripten

As mentioned in the last post, I am checking out ways to bring Syntensity to the web. As part of that, I just put up Emscripten on Google Code. Emscripten is an LLVM-to-JavaScript compiler. Combined with llvm-gcc, it lets you compile C/C++ code into JavaScript, and run that on the web.

Emscripten is still in an early stage, but can already compile some benchmarks. At this point I think I will start to try to port code I am interested in, and fix bugs along the way as I find them. I'll probably begin with a tiny subset of sauerbraten (probably one out of command.cpp, rendermodel.cpp, or physics.cpp) and see how that works, then continue from there.

The long-term goal is to run Syntensity, or a smaller version of it, on the web. Aside from Emscripten this will require some other tools, and probably a lot of hard work, so I can't say when I expect this to be done. Also I am working on it in my spare time, so that will vary depending on other stuff I'm doing. But now that Emscripten is in good enough shape to start using, the fun part can begin.

Side note: I'll post updates on this blog regarding using Emscripten for porting Syntensity to the web. I'll probably post stuff about Emscripten itself, that isn't related just to Syntensity, on my more general blog, here.

Update on Where Things are Going

It looks like the Syntensity codebase (and community) is going in two directions:

• A few community members (quaker, BiosElement) have started CubeCreate, a fork of Syntensity that is not afraid of breaking compatibility with Sauerbraten, in that they will rewrite Sauer code and add major new features. It definitely looks very interesting and they are putting a lot of effort into it. For more details, visit their IRC channel (#cubecreate on FreeNode), or forums.
  
  
• As for me, I have been thinking about something sort of in the opposite direction. I think gaming should move to the web - like everything else pretty much already has or is in the process of doing. To do that, things need to be - at least in the near future - lighter and simpler, to make moving to the web easier. So I've been working in my spare time on tools for that. One tool is an LLVM-to-JS compiler, which lets you run (some) C++ code inside of a web browser, by compiling it to LLVM and then to JavaScript. My goal is to move existing C++ code - Sauer, Syntensity, Bullet, etc. (or maybe simplified versions of those) - to the web that way. The tool is far from finished but already can run various benchmarks, I'll probably put the project up on some open source hosting site soon.

So those are the main directions in which things are going. They sort of go in opposite ways, but of course there's nothing wrong with that. The more the merrier ;)

Plan for Next Release: Metallblech

gk has a great concept for the next game, which you can see here. That game will be part of a new release.

Help from community members would be great, and let us get to the release faster. Stuff we will need help with includes

• Coding the new gk game linked to above. Mainly we will use existing scripts and customize them, but there will also be a few new things as well
  
• Testing that game
  
• Need to decide if to merge from the development branch for this release - if so, will require more testing time. Opinions?
• Making binary builds for Linux, Windows, OS X

There is no timeline, it really depends on how much help we get. But it will be awesome when it arrives! :)

Development Update

After the recent changes, we have been working out how to move forward. This is what makes sense for now.

Regarding code branches:

• The main github repo will remain as the stable branch. It will always be in sync with the running servers at syntensity.com, so if you want to connect to there, you should run that code.
• quaker66 has been doing excellent work on his branch, which is now the official development ('unstable') branch. quaker66 has worked very hard to port all the recent features from sauer svn (lots of great stuff that eihrul has been doing there) as well as awesome new features like flashlights, better cutscene management, etc. You can see videos of that stuff on his YouTube channel. In addition, T7g and BiosElement have been doing very interesting work as well, some of which has already been merged into quaker66's branch. New stuff should likewise be added to that branch.
  

Regarding versioning: The current version is still 1.1.6. For a new release, we would merge from the development branch, bringing all the changes from there. To do so, we would need:

• For the code to be stable and well-tested - after a reasonable code freeze. We might also want to wait for a short while after a new sauer release.
• At least one new cool game, to showcase the latest features
• To update the syntensity.com servers
• To have binaries for people to download

Short Absence - Almost Over

I just wanted to clarify why I haven't been around much the last 2 weeks. I relocated to Mountain View, California, and I started my new job at Mozilla. All very exciting stuff, but also kept me very busy.

However, I still would have been on IRC etc. on the weekend and possibly evenings, but I have had some trouble in getting my apartment connected to the internet (in silicon valley - somewhat ironic, heh). But that should be resolved in less than a week and I will finally be internet-enabled.

EDIT: AT&T fail - I am still without internet. They hope to get it working next week though.

Windows Installer

Thanks to community members gk and rapiscan, we now have a proper installer for Windows. It includes the latest code (1.1.6). You can check it out on our download page, which links to Mod DB.

If you do try it, please let us know how it works.

2 Interesting Videos

Two interesting Syntensity-related videos are embedded on the Bios Interactive blog, worth taking a look at.

New License: MIT

Today I changed the license on all my code in Syntensity/the Intensity Engine to the MIT (X11) license, for the reasons previously discussed in this blog.

The MIT license is a permissive software license, compatible with the GPL, and similar to the BSD. It it simpler than the BSD license in that the BSD has several variants, some of which have clauses that are not immediately clear - which was recently pointed out to me. (What does "Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission" mean, exactly?)

Mapmodel Mesh Collisions

The video shows a mapmodel with mesh collisions - so the player can collide with the mapmodel properly, and not with a bounding box. Note how the player can move through the holes in the model (but not through where the model is solid).

The mesh data is read from the sauer model, and converted and passed to Bullet, which handles the collisions. Scripts can also, optionally, create collision meshes on the fly.

EDIT: Btw, this is still a little buggy. For example, you need to rotate the mapmodel 180 degrees, and it doesn't notice other rotations for now. Use the bullet debugging option to see what is going on (/bulletdebug 1). EDIT 2: Fixed.

Personal and Project Changes

Some of you may have noticed that I have been less active on IRC (and in general) recently. The reason is that I was in the US for some job interviews. And the reason for that is that, as already mentioned on this blog, it looks like the business side of Syntensity won't work out, at least for me. So I can't continue to work on it fulltime as I have been for almost 2 years.

I still believe there is a lot of business potential here. But it would take someone with more industry contacts, business development skills, and money in the bank, than I do. Syntensity's technology works very well - I am very happy with it, and I think others are too - but I guess I was too optimistic about finding business partners and people to invest money in the venture and so forth.

Syntensity is open source, though, and that means anyone else can try to use it for a profitable business. And in fact some people are, and more will probably follow. (For more on that, and licensing changes, see below.)

I just signed a contract with one of the companies I interviewed at, and I'm going to start that job very soon, which I am very excited about (this blog post isn't about my new job, though, so I won't go into more detail now). But I am by no means leaving this open source project - I will continue to work on it in my spare time. I feel that this is a reasonable time for me to decrease my involvement, as

• The engine is feature-complete, at least for v1.0. More stuff would be nice, and will be added (in particular I'll work on finishing experimental stuff like Bullet, but also entirely new stuff that can be useful), but actually there is a lot of potential not even used by the current games. I have said it on IRC several times, what Syntensity really needs now is not more features, but more games.
• The engine is stable. Bugs are found, but most are in experimental features. The core stuff has been used daily for several months now, with few issues (and what issues did arise, have been resolved).
• More people are getting involved in development, in various ways. Hopefully the dev team will expand.
• There is a growing group of users that are helping others, which is a very good thing.
  

Basically, the engine is in a fairly mature state, and the community has come a long way from where it began. I would have been worried had I decreased my involvement before or around the 1.0 launch (and in fact that is one reason why I only started looking for a job recently), but now I have a very good feeling about the future of the project. And it is a healthy thing for the project as well, not to rely too much on a single person, at least once it gets to the proper stage - which I think it has. Also, after almost 2 years, it is time for a change for me personally, and I believe the new job I will soon start will be a great opportunity for me to do both interesting and important work, alongside some great people.

Some important stuff about Syntensity:

• Now that my personal business goals are irrelevant, the Syntensity/Intensity Engine name split is not really necessary (it was inspired by things like StatusNet/identi.ca, which clearly separate the open source project from a commercial use of it). So, henceforth the Intensity Engine may also be called the Syntensity Engine or just Syntensity. I won't bother to go through all the code and docs to change every reference to "Intensity Engine" to "Syntensity", but Syntensity is now the preferred name (it's shorter, and easier to google for). Note that syntensity.com will remain up of course, as a 'hub' for Syntensity game development, hosted by me, without change.
• I will be changing the licensing of the Intensity Engine/Syntensity, from GPL3 to the (new) BSD. Some of the reasons have already been mentioned in previous blog posts. Another is for the following reason: Allowing commercial use is a major goal of Syntensity, but for games that means non-GPL licenses are a must (you can't run GPL code on consoles, etc.). Dual-licensing with the GPL is possible, and was the general idea so far. But since I will have significantly less time for this project, and the business opportunities of dual-licensing no longer relevant for me, it doesn't make sense to deal with the complexities of dual-licensing (copyright assignment to some central entity, etc.). It is just simpler to move to the BSD license for all involved.
• Once I start working, I will be much less on IRC. However, I will of course continue to be active on the Forums, so feel free to use that in order to contact me, for stuff both important and nonimportant.
  

New Script Tutorial/Docs

Continuing the recent trend of writing docs, I wrote a new scripting tutorial, which is now present in the git repo. See

docs/scripting.markdown

That document refers to the example scripts in

docs/scripting_examples/

This should be a clear and easy way to get started with scripting in the Intensity Engine. I'll add more examples later on.

'Making a Game' Tutorial

There is an increasing amount of interest in using the Intensity Engine separately from syntensity.com, in some cases without a master server at all (like, say, for a singleplayer game). The engine supports this very well, but documentation has been lacking. So, I started to write a tutorial for that. Feedback is welcome.

Rain Effect

Somebody on IRC mentioned today that a rain effect would look nice, so I made a quick one:



Note how the rain is realistic in that it falls until it hits something, then shows a splash. So there is no rain inside the castle or underneath the scenery. This takes a little CPU, so very heavy rain (thousands of drops at once) might slow you down. In the video there are about 1,000 and speed seems ok.

The effect is about 40 lines of code, in library/1_3/CustomEffect.js. You can see it in action if you run the latest git, and play the storming_test map.

Editing Tools in JavaScript

The video shows a 'slope tool' that makes it easy to create sloped surfaces in cube geometry. It isn't finished, but it shows what can be achieved by this approach, I think.

Basically, this is done using new JavaScript API bindings to editing code that works on the cube octree. Actually the editing code is fairly old - it was used already in a very early version of the Intensity Engine - but it was not enabled in the current JavaScript API until this week.

Using the expressive power of JavaScript, it is easy to create editing tools like this one, for all sorts of purposes. For example it can be used to import maze files to create maps with them, etc.

You need to run the latest compiled engine for this. The code is in library/1_3/Editing.js, and you can see it in action in kripken/editdemo, which you can run by entering that name into the server_runner plugin GUI, after logging in to the master (see README-standalone.txt). To see it work as in the video, do /actionkey0 when hovering on one corner, then the same command when hovering on the opposite corner (this is just for demo purposes, not how the final controls should be).

Move to a Permissive License? (Part 2)

This is a followup to this post.

Following the previous post, I got some feedback in comments and on IRC. Here are some of the points raised, and comments on them:

• It was pointed out to me that zlib is the most permissive license of those mentioned, allowing binary copies to be made without attribution, whereas BSD still requires that you keep the copyright notice in that case (so you don't need to distribute the source, but you do need to document that you are using code written by whomever wrote it). It seems MIT does the same thing, but the wording is slightly less clear - BSD explicitly mentions source and binary distributions, while MIT just talks about 'copies of the software' (which many people seem to interpret as intending both source and binaries, but I would have expected to see something like 'copies or transformations of the software', where 'transformations' means compilation to binary form, etc.). So, out of zlib/BSD/MIT, I lean towards ('new') BSD.
  
  
• I should clarify my goals with the license change. There are basically two: First, I want the code to be useful for people, however it can be, which includes making money off of it in commercial games. My second goal is to improve the situation of open source in gaming - which is currently one of the last fields of software almost entirely dominated by proprietary code (compare the situation to operating systems, web browsers, web servers, databases, programming languages, etc. - open source is doing very well in all of those). I guess the two goals are not necessarily in perfect alignment, hence the need to think carefully about the license.
  
  
• Also I should clarify my own personal goals&status: I am looking for a job right now, so I will likely have less time for this project than I have had, but I certainly intend to continue contributing. Anyhow since we are past a stable 1.0 release, and the engine is in very good shape, really what we need now is more people creating games with it rather than more engine features that I add.
  
  About my role in the project, I would be very happy if the development team were to expand, and have more sharing of responsibilities. I've been talking to related projects and various people about that, and hopefully there will be progress on that front soon. Permissive licensing might make that easier, since with GPL projects it matters who owns copyright, whether you have copyright assignment or not, and all that, whereas in permissively licensed projects it is far less of an issue.
  
  
• I've been looking at open source code that is successful in gaming, for inspiration. Basically three projects come to mind, detailed below. I'm not sure what lesson to learn from them yet, but they are worth thinking about.
  
  
  • Quake Engine(s): Released as open source some time after the commercial releases, GPL with dual licensing. The GPL option has been used extensively in the open source community. However, the GPL uses did not become a significant force in gaming. Basically the GPL code releases play catchup, always being behind the closed code. Also, it is not certain that GPL code releases will continue after id Software was acquired by ZeniMax.
    
    
  • Ogre 3D: Used to be LGPL + optional commercial licenses, has moved to MIT. It is not clear yet if moving to the MIT license will change anything, as Ogre 3D was already doing very well before, including being used in commercial games. I am guessing that Ogre 3D has support for consoles, but that code isn't in the public repo (likely it can't be, because of the console SDK terms of use), which leads to a quasi-dual licensing model: Free for use (MIT) on regular computers, requires a license for consoles (or, implement all the console integration yourself, in theory).
    
    
  • Bullet: zlib licensed. The Bullet physics library is very popular, and has been used in many commercial applications, including ones that significantly modified Bullet, presumably without contributing changes back (but not sure). Unlike Ogre 3D, Bullet can be used on consoles freely, as there is really no need for special console integration code.
    
  
  

Move to a Permissive License?

I am considering relicensing all the code I wrote in this project to something more permissive, like zlib, BSD, Apache, etc. - basically, to let people use the code entirely freely. Please let me know whether you think that is a good idea or not, and if it is, which license we should switch to. This is a big decision - involving some 65,000 lines of code (about the same as Cube 2, btw) - so it should be done carefully.

As background, I chose the AGPL when I started, because I wanted to keep open the possibility of dual-licensing (to generate income for the project), and to make fragmentation of the community less likely. The situation with both of these has changed: I don't intend to make money myself from this project anymore (I still think it can be done - but it would take time, and before that time arrives, I will have run out of money myself...), and so far there seems little worry of fragmentation and incompatible forks.

So, I am considering moving to a license like zlib/BSD/etc., which are simpler and make life easier for people using the code - clear benefits, and could lead to more people using the code. Of course the flip side is that the code could then be used and modified in closed source projects without returning anything to the community. These are the usual tradeoffs between the BSD and GPL approaches.

Some thoughts on possible licenses:

• zlib: Same license as Cube 2, so kind of simple in that respect - a single license for almost the entire project (almost, because things like V8, ENet, Django, etc., have other licenses).
• BSD: Probably the most common permissive license out there, and the most familiar to people. Also worth mentioning, zlib is not an option on Google Code, while BSD is.
• Apache: Permissive, while adding some patent protections, which is useful. However, it does make the license text quite long and complex compared to zlib/BSD/MIT, which is a downside. Another downside is Apache is not compatible with GPL2, but is with GPL3. There are many codebases out there that are GPL2-only (including ones relevant to this project) so that is an issue.
  
• LGPL, MPL, etc.: More permissive than GPL&AGPL, but still some requirement of giving back, at least for changes to existing code. If the license is to be changed, I kind of tend not to go this route, because the current license is already quite close to it, since we don't consider games to be derivative works anyhow, which makes our AGPL sort of like the LGPL in that respect (a good comparison is how the Linux kernel is GPL, but you can run apps in userspace that are not GPLed). So really the actual change in going to one of these licenses is the removal of the 'A' from AGPL, that is, removing the condition of providing the source even if running over a network.
  

So, again, I am looking for feedback on this topic. We can also hold a vote if there are strong opinions and that makes sense. One thing though: Please let's not make this into a GPL vs. BSD flamewar with all the usual arguments we have all heard before - I ask that the discussion be about this project, which license makes sense for it (and not which license in general is 'better').

EDIT: Followups in this post.

Running Locally & Singleplayer

The server runner plugin can now work entirely offline - without connecting to anything remote, not even a master. In such a case it will run using the local files. Basically, running a map is now as easy as entering the name of the map in the GUI and clicking 'start'.

In such a situation you don't have any of the benefits of the master server, like getting the latest version of the game, being able to upload changes, play multiplayer or co-op games, etc. But, it is useful for when you don't have a network connection, for demos, or if you just want to run entirely standalone - like for a singleplayer game.

Speaking of singleplayer games, in a few lines of script the client can now be set up to automatically run a certain map using the plugin, which would basically turn the client into a single-purpose game: Start the client, and that game runs. If you also change the branding (logo, menus, etc.), it is now easy to use the Intensity Engine for your own singleplayer games.

(The underlying functionality for these new features is that you can set [Activity] force_location on the server, and it will run the map with that location, without querying the master. It will also communicate that fact to the client, so it does the same. The server runner plugin basically runs the server in a transparent way, with that feature enabled.)

Local Server Runner Plugin

People have complained that local editing and playing were harder than it should be. A plugin that I finished writing today, server_runner, should help with that. When the plugin is active, you can start a local server with just a few clicks in the GUI. The plugin will run the server in a separate process (so if your scripts crash the server, the client won't crash - kind of like how modern web browsers run plugins in separate processes).

Usage:

• Activate the plugin: Add intensity.components.server_runner to [Components] list in your settings.cfg
• After logging in to the master, click on 'plugins...' in the main menu. You will then see the status of the local server.
• Tell the plugin which map to run (simply by writing the location of the map, e.g. "racetrack" for the racing map). Then click start, and wait a bit while the server is started up for you. As soon as it is ready you will automatically connect to it.
• The server will be shut down automatically when you close the client, or connect to another server, so no need to worry about that. You can also shut it down in the GUI if you want (which is necessary to start it up with a different map).
  

Limitations:

• Requires you to be logged in to the master, but allowing master-less running would be possible if people want it.
• If the server crashes, output is saved to ~/.intensityengine_client/out_server.txt (note: not in the install directory, but the engine home directory). A nice GUI for viewing the output should be added later.
• You can't write the location of a map that you never played on before, as it only looks locally for translating the map location to the asset info.
• Tested on Linux. Should work on other OSes (it is 99% pure Python), but not tested yet.
• The server still uses a network port, so your firewall may ask about that. It would be possible to move to a pure IPC solution later, without that problem, but it would be additional work.
  

You must be running the latest git source code to use the plugin. If you do, I'd be happy to hear feedback on how things work.


Background:


Sauerbraten, the engine that the Intensity Engine is based on, lets you easily run a local server - it runs the server inside the client, in fact. This makes sense, since the Sauerbraten server is very simple, it is basically a network message router.

However, the Intensity Engine lets you run scripts and physics on the server, which raises the possibility of the server crashing (due to bugs in scripts, etc.). The server also can take a lot more CPU and RAM because of that. Consequently, the server is strictly separated from the client - there is no option to run it inside the client. Another reason is since the server now does a lot of the things the client does (scripts, physics), then maintaining a single codebase with the server defined as separate - and not two options, separate or internal - is much easier.

Bullet Physics

The embedded video shows the Bullet physics library being used in a Syntensity world. 100 boxes are simulated, as well as the static world geometry. As you can see, the boxes behave in a physically realistic way.

This is just an early demo - it would take more work to get this ready for actual games. But the hard integration part is now finished.

If you're curious to run this yourself, then instructions are at the end of the COMPILE.txt file.

Windows Building Improvements

Building on Windows should now be much easier:

• SDL (all parts) is bundled in the git repo in binary form, so you don't need to get that or set it up. These are the latest versions of SDL, which include some useful bugfixes.
• Likewise the latest zlib is bundled in binary form.
  
• Boost.Python is bundled in source code form, and compiles correctly, which prevents the need to get or set up Boost at all. This is very nice as the precompiled Boost we previously used assumed you were using Python 2.5. Consequently, the engine will now build using Python 2.6.

The process should now be very easy, basically just

• Get git, scons, CMake and Python.
• Get the Intensity Engine source code.
• Build V8.
• Run CMake to generate a VC++ project file.
• Build the project in VC++.
  

For specific details, as usual see the COMPILE.txt file.

I develop on Linux, so sometimes the Windows stuff gets delayed, sorry about that. Speaking of which, volunteers willing to help with Windows and OS X stuff would be very welcome.

Browser Plugin: Proof of Concept

In the following video you can see Syntensity being run inside a browser, as a plugin:



This is a followup to my post from last week, 3D and the Open Web. After the speculation in that post, I got to coding, and the result is a working proof of concept.


Status

The plugin works, as you can see in the video, and you can enter Intensity Engine servers (including Syntensity's) normally, just as you would with the regular client. This is still in early stages, however, so you should expect some limitations:

• The plugin will currently only build on Linux (where I develop). However the code on which I worked is cross-platform (see below), so this should not be a problem to remedy later. Meanwhile, Linux users can try it out for themselves using the instructions at the end of the COMPILE.txt file.
• Works in Firefox and Chrome, not tested elsewhere (that's Chrome you see in the video).
  
• Mouse input works reasonably well. Keyboard input should work as well, but doesn't, probably for some minor GDK reason I will look into later.
  

Technical Details and Notes

• Built using the O3D plugin code (which in turn is closely related to the Chrome codebase). The O3D code is not meant to be a general-purpose basis for browser plugins in general, so it took some hacking to get things working, especially to integrate with SDL (which we use for rendering and input). Not surprising I guess. Anyhow, the O3D code was very useful here, thank you to the authors!
  
• The implementation I wrote runs client instances in separate processes, which is good for security and stability. In other words, the browser plugin is a small component that runs actual clients (that render, run physics etc. etc.) in separate processes.
  
• Interprocess communication is done using boost::interprocess (Chrome's more powerful IPC turned out to be more complicated to set up, and anyhow it's probably overkill for what we need).
• Very few modifications were necessary in the main Intensity Engine codebase. Rendering is still done using SDL, etc. A couple of minor tweaks were needed here and there, though.
• A combination of Firefox and Chrome turned out to be useful during development - Firefox is easier to use in debug mode, to figure out crashes, while Chrome is more resilient to crashes bringing down the entire browser (although I hear Firefox will be adding a similar feature soon).
• Overall, my conclusion is that the browser plugin approach is not easy (there were several technical hurdles that I ran into, like this) - but it is possible.
  

Other Approaches

As an experiment, I think it is now clear that the browser plugin way is feasible. It's still an open question of whether it is the best approach, or whether one of the alternatives (mentioned in the previous post) would make more sense. I tend to favor this approach though (making our own browser plugin), for the following reasons.

I have gotten no response on the O3D mailing list, where I asked about possible collaboration (like contributing our code to there, to add features games need like networking, physics, etc.). I guess it isn't relevant for them. In that case, it probably doesn't make sense for us to move to O3D - porting the rendering engine would be a lot of work, and it turns out that making our own browser plugin (in part using their non-rendering code) is feasible.

WebGL seems to be favored by some people in the virtual worlds community. It's definitely an interesting technology, but I am doubtful it would work for games, or more specifically action games like we have in Syntensity, for several reasons:

• WebGL is not complete, and WebGL's performance limitations are not yet clear (and not sure when they will be).
• WebGL + JavaScript - a pure web implementation - would be too slow for very complex clientside physics. NaCl might help with that, eventually.
  
• Network protocol-wise, TCP (even with nifty things like Comet, etc.) can't give the performance that UDP can, in terms of realtime updates.
• Also, it is unclear if WebGL will ever make its way into Internet Explorer. After all, WebGL is based on OpenGL, which Microsoft has been trying to kill. A related issue is that not only is a major browser hostile to WebGL, but also a major desktop operating system - users often need to manually install OpenGL drivers from the manufacturer's website, which is no better than installing a browser plugin (in some ways worse).
  

That said, the Intensity Engine has always been a web-oriented project, what with JavaScript used for scripting, HTTP for asset downloads, asset and server management done using a web interface (on Django), etc., so if later on WebGL matures into something relevant for us, we can certainly consider moving to it.


Bottom Line

The open source community can have something like a FOSS Quake Live, or more generally a proper open solution for 3D content on the web, from casual stuff to multiplayer action games. The potential here is vast, and it is within reach, basically right now.

If we are to go forward with this, we will need help from the open source community, as browser plugins need a lot of testing on all the different operating systems and browsers and so forth. So, help is welcome. Also, ideas on how to do things would be appreciated, in particular about how to get the licensing issue right - as mentioned in the previous post, if changing our license will get more people on board, we are open to discussing that.

3D and the Open Web

This post is a call for feedback, about Syntensity's engine (the Intensity Engine) being used on the web. The basic idea is that we - people on the web - should avoid what happened with Flash, a single vendor controlling a closed technology, which became the de facto standard for video and interactive content for many years. Instead, we need an open source solution, not controlled by any one corporation. I think the Intensity Engine is close to being suitable for that, and am looking for feedback on this idea, and help in achieving it.

A big part of the success of the web is its openness: We can run websites on any of several webservers, some of them open source (Apache, lighttpd, nginx, etc.), and visit those websites using likewise open source web browsers (Firefox, Chromium, etc.). That's an amazing achievement. And let's not forget that just a few years ago Internet Explorer was dangerously close to a choke hold on the web browser side.

Video, these days, is often in the tech news: Specifically, using open, standardized technologies to play video on the web, using HTML5. There are some problems along the way, but overall we might be close to getting past video on the web being entirely reliant on Flash - a closed-source product controlled by a single company, and one that doesn't necessarily perform as well or the same on all platforms.

Here I'd like to talk about the "3D Web". The term was overhyped in the past, but really all I mean here is 3D content, mainly games and virtual worlds, that are accessible on the web. This is currently a smaller area than the web in general, or even video on the web, but it is growing in importance. My concern is that the open web should avoid 'Flashification' of 3D content, where a single closed-source product becomes the de-facto standard in the area, like Flash had (and mostly still has) in video, 2D gaming and interactive content. If we want to avoid that, the time is now.

There are some open technologies that show promise, mainly WebGL and Google's O3D. These may well end up succeeding. However, neither is a complete game engine, like for example the Unity 3D web plugin. There is a lot more that is necessary over what is present in WebGL and O3D - physics, content creation tools, a proper API and useful libraries, network protocols (for multiplayer), etc. etc. Some of that might be added to WebGL and O3D using JavaScript. However, many games are too computationally intensive, even with the best JavaScript engines out there.

Perhaps at some point Google Native Client (NaCl) will allow running game engines on the web. But instead of entirely relying on that, I think the open web needs an open source 3D gaming engine. The time to do it is now, before something else non-open comes to dominate the field. I'd like to suggest the Intensity Engine for that purpose: It is a complete, stable, cross-platform game engine. It works right now (outside of browsers) and has been in production for several months, successfully, on syntensity.com. It is 100% open source, and the current license, the AGPL, can be modified immediately to something else, like the BSD license, if that makes sense for this purpose. Also, the Intensity Engine was built with something like the web in mind - we use JavaScript to create games (Google V8 right now, and we also did some tests with SpiderMonkey), for example. In our mind, the ability to download and run games was always in parallel to how web browsers download and run web pages.

One concrete idea among others is to port the Intensity Engine's rendering system to O3D, and build a browser plugin of the result. The benefit being O3D is already set up as a browser plugin, while the Intensity Engine provides all the other game engine stuff. Alternatively, we can just port the Intensity Engine as-is to be a web browser plugin, assuming that would work with SDL (if not, would need to work on replacing that).

So, I'm looking for feedback about this topic, and ideas and help for how to move it forward. I really feel it isn't just us over here (in 3D gaming) that care about this stuff - lots of people want the web to remain open, and that should include 3D content and games.

Thanks for your responses!

Edit: I posted on relevant mailing lists about this,

• o3d-discuss
  
• WebGL
  
• mozilla-labs
  

Local Storage Plugin

A new plugin has just been committed, local storage, which lets you store key-value pairs locally. It's currently being used to persist the high scores in the Racing game.

Usage:

• Add intensity.components.local_storage to the proper place ([Components] list) in your settings.cfg, so the plugin will be loaded.
• In your scripts, do CAPI.signalComponent('LocalStorage', 'read|KEY'); to read the value for KEY. You will get in response a string (all output from signalComponent is in string form), so do eval() on that. The result will be a list of responses from components. Normally you will have only one storage component, so just get the value at index [0].
• To write values, do CAPI.signalComponent('LocalStorage', 'write|KEY|VALUE'); to write that KEY-VALUE pair.
  

That's basically it. See also the source file for some technical docs and notes.

New Forums on FreeGameDev

We have recently been given a space on the FreeGameDev Forums, which is a much better place for community discussion than our current forum page. You can check out our new forums there at this link.

Aside from a more standard and useful forum approach - subforums, topics, etc. - it also makes a lot of sense for us to do it on FreeGameDev, because we share their approach about combining free and open source software with gaming. Gaming is, sadly, one of the last areas to which open source has not yet made a big impression. Most game engines are entirely closed source, and in fact many games also run entirely on locked-down hardware (consoles).

But that isn't how things need to be, and I predict they will change. The are reasons that led to our having open source operating systems, web browsers, web servers, and so forth, that are either better than or equivalent to competing closed source products, and those reasons are essentially the same in gaming.

So, having forums as part of the FreeGameDev Forums makes a lot of sense, and I hope it will lead to more interaction between Syntensity people and other open source game creators.

Thanks to the FreeGameDev people for agreeing to host our forums there!

Progress on Mac OS X support

Thanks to abs1nth, the client now compiles on Snow Leopard (and possibly other versions). To do so, get the latest git source and follow the OS X section in the COMPILE.txt file.

The move to CMake, and removing the external dependency on Boost, made this more feasible than before (and they also make building on Windows easier).

HOWTO: Make your own Razanak maps/levels

In Syntensity everything is moddable. That includes Razanak, the game we launched recently. Below is a step-by-step guide to starting your own Razanak-type map.

"Razanak-type map" means: Everything will be exactly the same as in Razanak - gameplay, entity types, HUD, etc. etc. - except for the map itself and entities in it. That means you can create the level however you want: You can add corridors, caverns, water, spawnpoints for the spider robots, rocket turrets, doors, keycards, pickups, and so forth, however you want. You can make levels similar to the existing one, or entirely different ones - it's up to you.

Here are the steps to follow, to prepare a new map based on Razanak:

1. Click on Razanak in the list of running servers and activities. This gets you into the Razanak activity.
2. Click on the map asset. This gets you into the actual asset containing the map. (You could have gone here directly if you had a link, instead of through the activity, so step 1 isn't really needed. But it's how you might usually do things.)
3. Click 'clone'. You now have a copy of the map that you can edit, as its owner. (Note that to do this step you need to be logged in on the master website.)
4. Change the 'location' of the asset. The location is where it will be downloaded to in the asset storage areas on the client and server. If you don't change it, it will stay the same as Razanak itself, which means that you will re-download Razanak and this map if you play one and then the other (since each such download will overwrite the one before it). Instead, change the location to something like base/USERNAME/mapname.tar.gz where USERNAME is your username (you don't need to do it that way, but it is nice and orderly).
5. Click "Create an activity based on this asset" to create an activity. You now have an activity, which you can run on servers (assets by themselves cannot be run).
6. Rename the activity, to something you like.
7. Click "Requisition a server instance to run this activity". One of the Syntensity servers will then run your copy of the map. You should see it in the list of your requisitioned servers.
8. Connect to the running server instance. The simplest way is to run the client, login, enter the lobby, and look in the side room on the right. It will have portals to all the currently running servers. Walk into the one running your new map. You should then see the familiar Razanak map load.
   
9. Press 'e' to enter edit mode. You can't do that on Razanak, but you are an owner of this copy, so you can do it now.
10. Do /clearallents. That will erase all the entities in the map. Razanak has about 1,000 entities, and some of them require CPU to manage, so after doing this you will probably see the frame rate go nicely up.
11. Do /newmap. That will erase all the world geometry. Note that you might not see any ground at all, but don't worry about that right now. Also, the map textures have been erased, so you shouldn't try to actually do any editing right now. Just go on to the next step.
12. Edit the map.js for your new map, as follows. You can edit it with an editor of your choice, the file is in ~/.intensityengine_client/packages/base/LOCATION-OF-YOUR-MAP (that you decided on in step 4). (Note that you should edit the map.js in the directory with the name of the location - and without .tar.gz - and not the archive ending in tar.gz.) (In Windows, replace ~ with C:\Users\USER or C:\Documents and Settings\USER, etc.). Or, you can use the in-game editor, press Escape and then editing commands...->cfg (then do 'load'). The actual editing you need to do is to add these two lines at the *top* of the very short map.js already there:
    
    Global.entitiesFile = './entities.json';
    Global.noCutscenes = true;
    
    The first line tells the map to use your entities data (not Razanak's), and the second tells the map not to use Razanak's cutscenes. Again, be sure to place these two lines *before* the existing line.
    
    
13. Do 'upload map...' (press Escape first for the menu). When the upload finishes, the new version of the map will run on the server and you will be placed in it automatically.

You can now start mapping! More details about mapping and creating in general are on the wiki, and as usual feel free to ask for help on IRC (#syntensity on FreeNode) and the forum.

Tip: To get started, you might want to add a WorldMarker (press F8 in edit mode, and select WorldMarker in the second tab), for which you edit the 'tags' field (rightclick on the entity) to [start_red] (note the [, ] symbols). That will be the position where the players start ('red' is the name of the team, which should really be named something else, but the default team names are 'red' and 'blue').

Razanak a.k.a Swarm

After much work, 'Swarm' has been launched, and is in the lobby. It is now named Razanak (thanks BiosElement!), which is 'Swarm' in Hungarian (give or take a few letters).

To see all the visuals correctly, you need the 1.1.5 or 1.1.6 builds. You can currently log in with older versions, but that will be disabled very soon (possibly by the time you read this). The latest builds can be downloaded from the download page (optionally, you can also compile from source if you want). We hope to have builds with nicer installers, and for more platforms, soon.

Currently there is one (big) level, with a boss at the end (that can be quite hard to kill). We plan to add more levels soon, they should be much faster to create now that the code is all ready.

Have fun, and let us know what you think!

Help us name and test 'Swarm'

We're almost finished with 'Swarm', and we'd really appreciate some help with naming it, and playtesting. So, if you want to help, check it out here:

http://www.syntensity.com:8888/tracker/activity/view/46183c34_3b4f_44dd_9a63_4ca498603bf1/

and here is a video:



'Swarm' isn't in the lobby world yet, since it isn't finished. To test it, you need to requisition a server. If you need help in doing that, there are usually people on IRC (#syntensity on FreeNode) that can assist you.

So, as already mentioned, at this point we are looking for a final name for this map ('Swarm' is just the codename). Feel free to suggest any and all names that you think make sense!

Also, the map is ready for playtesting - everything should basically work, except for the boss at the end, which works but wasn't tested much yet. So if you find a bug or have a suggestion for how to improve something, that would be great (we probably won't change anything major at this point, though - just minor stuff. Big changes will wait for after we release the stable version of the game).

Note that a recent build of the engine is necessary, preferably from source. Otherwise the visuals might not look as good as they should. We should have new builds available soon.