home / blog / podcasts / notes / photos / about / more

Multiplayer 3D Shooter in the Browser

could be the next big thing

Posted by Jeena

Me and my brother are trying to write a multiplayer browser game. We have been working on it for a long time already, because it is a hobby project for both of us. It is really fun to research all the things which are necessary and while doing that today I found out that the web soon could be a platform for big ass games.

Network speed

So games, in contrast to other applications, are particularly resource hungry, especially multiplayer games with 3D graphics which you play over the internet as your network.

Traditionally we've only been using TCP on the web because HTTP is the protocol on the web and it is a layer on top of TCP. TCP is cool because you can send data once and, if it doesn't timeout, your data will arrive exactly like you send it, even in the exact order. From my bachelor thesis (2.3.2):

For reliable transfers TCP is often used on the Internet. Built in to the protocol are the error checking and correction mechanisms missing in UDP. This ensures the consistency of data, but also makes the transfer slower than if UDP had been used.

In games positions of your opponents, etc. are updated every couple of milliseconds, so it doesn't matter if you miss some in between. The bigger problem is that with TCP even if newer information would arrive, your program doesn't receive it until the slowest one arrives, after that you get all the packages at once, which then makes it look like your opponents are teleporting themselves all over the place.

So game developers would like to use UDP. But for a couple of reasons you can't do that from JavaScript, most notably security and DDOS. But there might just be a middle ground:

WebRTC

Perhaps you have heard about WebRTC in connection with peer to peer audio and video chat, the Skype killer! But there is more.

First of all, WebRTC uses UDP and has support for peer-to-peer connections, so it is fast as you can see with the video-chats, second, there is not only a media data API but there are also Data Channels. With those you are able to send data via UDP and peer-to-peer in a safe manner, which is exactly what we need for our real time games.

So this is convenient, the network part of our game is covered, but what about the graphics?

WebGL

Many of the big game titles are written in Direct X, therefore they are not portable and will only run on Windows. But there is more and more movement away from this.

Last year we finally got Steam for Linux (we got it for OS X even earlier) and I assume you've herd about Steam machines, which is Valves take on game consoles, which run on Linux too. Obviously there is no Direct X for Linux or OS X but there is OpenGL, which kind of does the same thing (honestly I have yet to understand why people choose to write in Direct X - needs more research). With OpenGL you can implement all the cool 3D graphics stuff and it is available for all the platforms out there.

And it gets even better, there is WebGL. WebGL is based on OpenGL ES 2.0 which is a subset of the OpenGL which has been in use on mobile platforms for years already. All the cool 3D games for iPhone and Android you've been playing? That was OpenGL ES which is what WebGL basically is.

Want to see something cool? Check out the WebGL Shader Editor in the Firefox Developer Tools:

What you can see there is so cool! Normally when you're writing shader code, etc. after each change you have to recompile your application and go to the part in the game where you changed something to see it. With the Shader Editor your view changes as you type, just like live CSS changes in Firebug.

Obviously because WebGL is based on OpenGL ES 2.0 it won't have all the cool stuff you have in the newest and greatest full blown OpenGL 4.4 but in comparison to what we had before that it is just mind-blowing that you can actually program the GPU of your graphics card from the browser. Who would have thought that back when we were all fighting IE6 bugs a couple of years ago?

Computation speed

So with network and graphics covered, what about the CPU? Isn't JavaScript way too slow for big ass games like Call of Duty or Battlefield where you constantly have to recalculate the physics, the AI for npc:s, etc.? So, yes it depends on the game obviously but there is some really cool stuff coming which will help us out here:

asm.js

asm.js an extraordinarily optimizable, low-level subset of JavaScript

Q. What kind of performance benefits can I expect to get with asm.js? A. It's early to say, but our preliminary benchmarks of C programs compiled to asm.js are usually within a factor of 2 slowdown over native compilation with clang. We will publish more benchmarks as we collect them.

Did you get it? It takes only double the time to run the asm.js JavaScript code in comparison to a native C(++) implementation. WTF?! Check also out the rest of their faq. Modern non asm.js JavaScript (for example in in V8) nowadays is about 5 times slower then native code.

Emscripten

asm.js in combination with Emscripten, which is a LLVM-to-JavaScript Compiler, will allow you to keep writing your game in C++ but to compile it to JavaScript and then asm.js to run it in the browser with only slowdown factor of about two. You can keep using all your C++ libs, you just add a step to your build tool chain.

NaCL

And there is even more, while asm.js is implemented in some Firefox versions, Google came up with a different solution to the performance problem, Native Client:

Native Client is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user's operating system. Portable Native Client extends that technology with architecture independence, letting developers compile their code once to run in any website and on any architecture.

In short, Native Client brings the performance and low-level control of native code to modern web browsers, without sacrificing the security and portability of the web.

When this is implemented then you won't even need to recompile your C++ code to JavaScript and won't even get the factor two slowdown, this is just mindblowing.

What is the state of all of this right now?

"This is all fine and dandy but it will take years until we can use any of this!" I hear you cry. The fact is you can use most of it already today with your normal Firefox or Chrome!

Yes you can play multiplayer 3D shooter in your browser today, there is even a demo game called BannanaBread

BannanaBread scene:

BananaBread is a 3D first person shooter that runs on the web. It takes the Cube 2: Sauerbraten engine, which is written in C++ and OpenGL, and compiles it using Emscripten into JavaScript and WebGL so that it can run in modern browsers using standards-based web APIs even without the need for plugins.

The latest update of this demo uses asm.js for additional speed, and WebRTC for multiplayer.

Go and check it out right now, it is amazing what is possible in the browser today, and thanks to webstandards you can even chose between different browsers to run it. But be aware of the fact that you still need a good graphics card to get it to run smoothly.

Why should anyone care?

The web is an open platform and everybody and their dog already have a browser installed. Just think about all the people playing on Facebook or all the other small games.

If for example World of Warcraft, which is already written in OpenGL and could be recompiled with Emscripten to asm.js to be run in the browser without much of a penalty, they would get a ton of new more casual users. They already have a subscription business model, so they don't need to keep selling the game. And as a user you just go to their website and start playing, without hours of installation or waiting in line to get your copy or anything.

I think in the end this will be the winning model anyway, subscription instead of selling copies which later on can be resold or cracked.

It would crash the market for cloud gaming where the idea was that companies run and render everything on big servers and the clients would just get a video stream to their thin client. This way you don't even need fat servers because all the heavy lifting is done by the browsers, even without even the need to install any software, not even a browser plugin, if the users have a good graphics cards in their computer that is.

Have you written a response? Let me know the URL:

There's also indie comments (webmentions) support.