So you want to be a Browser Game Developer? (about Turbulenz and other engines)

…an HTML5/CSS3/JavaScript Game Developer, that is?

Turns out you have various choices to proceed.

0) Develop your own JavaScript game engine – NOT. There’s a plethora of game engines out there already. I checked a couple of them out today and even if you choose to develop your own, be aware there might be one out there that very well suits your needs. There’s a comprehensive list here and if something is missing you can add it there like I did today.

1) Try to avoid JavaScript altogether (I wouldn’t blame you), use an existing C/C++ game engine and compile it with Emscripten. I covered Emscripten before and if you are into C/C++ programming already, this might be the way to go – especially if you want to avoid a programming language that was developed in ten days.

2) Use Turbulenz which went open source this week. From my experiments today it’s a game engine done right – it has a building tools (written in python – yay!), it has tons of features and (gasp!) loads of documentation. The thing that bought me was the fact that I had no problems to install and run it and especially the impressive performance of  this Quake 4 asset import:

3) If options 1 to 2 are too heavy then – again – I recommend to check out the list that I mentioned above. The library I intend to check out is the iio engine (that’s the one I added) and I also intend to write tutorials on using it in the near future aimed at people starting out on JavaScript games (if you are interested, leave a comment).

4) If you just want to start without any installation – the Pixieengine is an online IDE (editor) and you can develop right away from inside your browser (and export it or embed an iframe if the environment allows it).

So get out there and roll the bones!

Source code of the minimal first person webGL demo

I forgot to mention that I uploaded the sources to the minimal FPS that I mentioned in my last post ‘Towards open game engines in the browser‘. Hopefully this gives a head start to someone who wants to combine 3D (Three.JS), physics (Cannon.JS)  and first person controls.

You can find the repository on Github.

 

[EDIT]:

Towards open game engines in the browser

I started a series of experiments towards a game engine in the browser. This is part of a bigger plan that I hopefully get sorted out soon and write down eventually*.

To me, there are two paths to follow towards games** in the browser and I will follow both of them.

The ‘Bananabread’ way

Taking a full fledged game engine like Cube2 is the way that Alon Zakai is following – his Emscripten process is compiling it to pure Javascript and ports Bananabread to the browser. At this very time of writing he is adding the last missing piece to it – network support.

I cannot stress enough how incredibely cool this is.

The JavaScript library way

A ‘game engine’ comprises usually a couple of different components and it turns out that you find open source JavaScript libraries for nearly (?) every purpose of such an engine – sometimes even more than one.

• 2D graphics: Raphaël, D3 (etc etc)
• 3D graphics: Three.JS, SceneJS (etc)
• physics: Cannon.JS, Ammo.JS (etc)
• audio: Webaudio.JS (etc)
• persistence: FileSystem API
• controls: PointerLockControls
• networking: SocketIO, WebRTC
• scripting: well, JavaScript obviously? (or CoffeeScript, Brython)

This list is by far not complete (more complete lists here and here) and I am probably missing some bullets and some libraries which even underlines my point: everything seems to be there.

To get a grip on it myself, I took a 3D engine, a physics engine and the first person controls and build a little demo, sporting an (albeit unsophisticated) Blender model and some dynamic objects:

Why is this important?

There is absolutely nothing wrong with proprietary concepts like the Unity Engine, not even with Flash.

I still think it’s important to be able to create something right in your Browser – both Mozilla and Google are working towards turning their browsers into multimedia engines and add the parts missing in a spectacular speed.

Most of the components needed are already there, so why not use them?

But even more important: all of these libraries are open source. This means we can not only use them for free, but we can learn from them, combine them and maybe enhance them to something that the original authors may have never thought of.

So – what keeps you from building?

* Rob Hawkes (former Mozilla) has written an excellent post which includes some aspects of the bigger plan™.

*Disclaimer: when I say games I mean the good definition of games like in  “cutting edge real-time database network application with multimedia frontend for entertainment” and not the awkward german definition of  “it’s fun so it can’t be serious”.  And no, I won’t grow up.

[EDIT] The source code to the demo is on Github.

[EDIT2]

Blender view

News on BananaBread

Recently I had the honour to talk to Alon Zakai, the creator of Emscripten, a C/C++ to JavaScript Compiler. Yes, you read that right – a C/C++ to Javascript compiler. Actually it is even more. Why this makes sense, and what this has to do with web or 3D or web3d is what this post is about.

Alon Zakai is a researcher at Mozilla, the company that brings us not only Firefox but also a lot of open source projects like BrowserQuest (I wrote about it here) and of course BananaBread from the man himself.

He left a comment here stating:

I’d love to work with people that want to make a more virtual worlds thing with this technology – basically doing as you said, starting with Cube 2 or Sandbox, using the BananaBread HTML 5 on that, and adding virtual worlds features. There is a lot of potential in that approach, if people want to work on it.

I read about Emscripten before, at first in the highly recommended DailyJS blog. It sounded like a swiss army knife to turn, like, everything! to the web – way too good, to be true. They wrote a H264 video decoder in JS? Yeah, right.

But to learn that it works (read: really works) and that it could be a real game changer (pun intended) was awesome. Here are the key issued we were talking about in a nutshell and compiled from memory.

The bad news!

No bad news. Now – on to the good news.

How hard was it to turn the Cube2 engine into a browser game?

Not too hard. The time consuming part was to get the webgl context into Emscripten, because it wasn’t implemented yet.

Is it possible to turn BananaBread into a multiplayer game like Cube2?

Yes.

All the multiplayer code is still in, because the engine works with a local server. The only thing that needs to be implemented is some sort of TCP/UDP socket implementation. So if anyone with either websockets or WebRTC know-how steps in, we are good to go.

You mean ….?

Yes, Alon plans to get this implemented in 2013. This. Is. Awesome.

Why does Mozilla support Emscripten?

Now, this is important. The reason is: Mozilla believes in the openness of the Internet. Contrary to popular believe Mozilla is not competing with Google (or any other browser developer for that matter) because there is a competition between Firefox and Chrome.  The real problem are walled garden like Apples store, tempting developers into creating something as an app when it could be web app. Emscripten helps to bring ‘real’ programs into the browser, with no or small changes and with very reasonable performance. There is already a huge variety of applications available from games to text-to-speech synthesizers to full programming languages (python, ruby, lua etc.)

Next steps?

Note to self: get Emscripten to run on Amazon EC2 and get BananaBread going. More about that on this channel.