Torque2D… in a web browser?!

For anyone following the indie game development tool market, there’s one thing that just about every popular commercial tool has: the ability to export your game to the web. Being able to run your code in a web browser is an extremely powerful tool, not only from a platform standpoint but also because it eliminates the requirement of having to install anything.

The tools for doing this in the past sadly either required the end-user to install something (if you made your own plugin), or conforming to a strange runtime (flash, unity, java). Torque itself at one point went with the “make your own plugin” approach, which to say the least was a disaster since every developer had to go through the hurdle of making a plugin for each major system and ultimately the end-user had to install something. Unless your game is the best thing since Minecraft, this approach will never work.

Thankfully now there are several more promising solutions on the horizon, one of which is Emscripten. Emscripten is a compiler that takes standard C/C++ code and compiles it to Javascript suitable for running in any modern web browser. In essence as long as you have a modern 3d graphics card and HTML5-capable browser, you should be able to run just about any game code on all major platforms!

Getting to the point, over the past few weeks I’ve been working on a port of the Torque2D game engine to Emscripten. After a bit of help from the Emscripten developers, nearly everything works (excluding networking).

Torque2D Emscripten

On a time scale, the basic port took a weekend while the bug fixing was spread over the next few weeks. Porting across code to Emscripten was relatively easy since it exposes a pretty standard unix API with SDL, OpenGL, OpenAL, and a few other useful APIs. However the difficulty was multiplied somewhat when I discovered some rather nasty memory corruption bugs.

Firstly there was a problem with the dynamic_cast handler, in which a cast would fail for no apparent reason. It turns out a key map in the input code was a bit too small, causing an overflow which corrupted some memory related to handling the cast. There was also a problem in the scripting engine in which script strings would randomly be corrupted which I ended up hacking around.

Sadly Emscriptens debugging facilities were not up to the task in this case. While there were several facilities to debug memory corruption, none of them picked up on these issues. Unfortunately this meant  I had to go through every major bit of code to eliminate what was causing the problem, which took a considerable amount of time.

Another thing to note is Emscriptens OpenAL implementation was missing a few crucial functions, though these were fairly trivial to implement.

Overall I was quite impressed with Emscripten, though it would be nice if there were more debugging facilities or even some form of GDB frontend so I could more easily step through code.

For your enjoyment, A build of the port can be found here: