JavaScript vs C++: Creating the same 3D game in both

I wrote the exact same first person shooter 3D game both in C++ and JavaScript. In this article, I am writing down my findings. Please skip the next indented paragraph if you are not interested in the background details.

A few years ago, when WebGL started to work in most browsers, I had the idea to write a first person shooter game in JavaScript and HTML. It was a crazy idea back then, but it worked, and the performance wasn't that bad (try it out yourself). I extended the game's code in my free time, and after a few years, a lot of features were added, and the game started to be fun.

Then, Electron arrived (basically it's a way to bundle your website in a package together with the Chrome browser and pretend you created a native app), and I thought:

"Woha! Why not make a real native app out of my WebGL game? I only put it into Electron and that's it!"

I did that, and Electron worked surprisingly well. Nice piece of software. But the result wasn't very convincing: Although I put a lot of effort into making the electron app feel like a native app instead of a HTML site, it had a lot of drawbacks like input lag, lack of hardware, 3D and fullscreen settings, bad working cursor locking and similar.

So I decided to rewrite the entire game in C++. Because - why not. And it shouldn't be that complicated: The JavaScript code of the game is based on the open source 3D engine CopperLicht (which I created), which has a similar API to the C++ 3D engine Irrlicht (which I created too), on which my game engine Framework CopperCube is based on anyway. So it wasn't that much work, I only had to rewrite the game logic. Everything else, from Window / UI / Collision / Font / Texture / Sound / Image / File handling etc was already there, with a very similar API.

The port was done within a handful of weekends and the game is now a native Win32 C++ program. You can try it if you like.

Comparison

So now, I have a rare possibility to compare the development of the same app written both in C++ and JavaScript:

Performance

This was the biggest surprise for me: The performance of both implementations is very comparable. Even the most CPU intensive parts, namely procedural generation of houses and the collision detection for the physics engine run at acceptable speed in JavaScript. And only about twice as slow as in the C++ version. Chrome's JavaScript optimization is really impressive. Unfortunately, the JavaScript version of the game feels to be much, much slower. See next why.

Control of the details

While I have full control of nearly everything in my C++ implementation, I need to rely on the browser for a lot of things in the JavaScript version of the game. And that's where the problem is. The procedural generation of the world is laggy in the JavaScript version, because some WebGL calls sometimes shortly freeze the browser. It is just a few milliseconds, but these aggregate and slow down the game very much. I wrote several workarounds solving some cases, only for other cases to appear, unfortunately. In C++, you have direct access to everything, so if a problem like this appears, you have much more ways to work around them.

The JavaScript version runs at a similar speed as the C++ version, at about 120 frames per second on my development system. But the JavaScript version *feels* very, very slow. Depending on your operating system and hardware, the browser behaves differently, and with a lot of combinations, input is laggy. Even if drawing the scene very fast, mouse input is lagging behind, and especially for a first person shooter game, the game feels very slow because of that. You have two methods of doing a "game loop" when using WebGL: requestAnimationFrame() and setInterval(). One version solves this issue sometimes on some systems, one version sometimes on other systems. It's quite frustrating.

There were similar problems, but they all had this in common: With JavaScript, you are depending on the implementation of the browser, which isn't always doing what you need, unfortunately. In C++, that's not a problem.

Development speed

I'm quite fluent in both JavaScript and C++, and I feel that both languages have about the same development speed. You have to type quite a bit more usually in C++ than in JavaScript, but C++'s type system makes it easier to find certain types of bugs earlier, usually. Thanks to modern browsers, debugging is as nice in JavaScript as it has been for nearly two decades in C++. For me, personally, both are languages with their weaknesses and strenghts, but after all, they are just tools to get the job done.

Recap

If you ever want to create a first person shooter 3D game and sell it as native game, I'd recommend not to do it in JavaScript/HTML/WebGL. It's fine for games in websites and prototypes but not to be treated as finished native product. At least not now. But who knows: in a few years, the situation will look better. I know a lot of people are creating 2D games successfully that way. And it seems to work nicely. But for me, 3D from the first person view hasn't worked yet.

For now, I'm developing my game further in C++. And hope to have it finished within the next months. You can follow its progress on its website, if you like.



First Windows .exe build

I uploaded the first build of the game for Windows here. The game now runs at about 150 FPS instead of the felt 10 FPS when it ran inside a browser.

I also re-created the gameplay video with that build, I think you can see now that it feels much, much smoother now:



Any feedback of the build would be welcome, it is just a 12 MB download.



Borders

I originally wanted the game to have no borders, and an unlimited area to explore, but for technical reasons (floating point precision), I now limited it to an area of about 120 square kilometers (or 75 square miles). The border looks like this:

It is a bit abrupt, but the only way to keep the player from climbing over it. I think 120 kmē is still enough to play the game and have fun.



Constant Reminder

From now on, even when drinking beverages this should remind me to keep pushing the game further towards release:

I'll do my best... :)



GreenLit!

Well, that was fast. My game was just greenlit today:

I will polish the game quite a bit and refine and beta test it before launching on Steam, so this will take a while. But this is great news! Thanks for all the support and to all the people voting for the game!



Now on Steam Greenlight

After I made that video from my last post, people suggested that I could add my game to Steam Greenlight. Since I have a nicely working Windows .exe build I now did: PostCollapse is now on Steam Greenlight.

Unfortunately, the video apparently sucks in contrast to the screenshots... which again I think might be affecting the votes negatively. If you like to help, please vote too. :)



Gameplay Video

Last weekend, I thought it would maybe be a good idea to create a gameplay video of that game I am working on. Here is it, what do you think?



Constructive feedback welcome!



Steam Summer Sale 2016

It's this time of the year again, Steam is in Summer Sale mode. CopperCube is of course also discounted during this time:

You can get it here.

I'm not sure why a lot of people on steam seem to complain about the 'small' discounts. Did you see that -86% on CopperCube? That's insane, if you ask me. :D



RocketCake 1.2

I had so much to do during the last weeks, I forgot to mention on this blog that I released version 1.2 of my free responsive website designer RocketCake. There are a few new templates in that version, improved master/client code support, support for radio buttons (somehow I forgot those, and no one complained!) and a few bug fixes here and there.

The editor is still only a few months out of beta, and already used by quite a lot of people. I'm quite happy about this.



The Android SDK Manager is now blatantly lying

A lot of people using CopperCube to create 3D Android apps suddenly complained that setting up the Android SDK for them newly doesn't work anymore. The Android SDK Manager would simply refuse to download the required API 8, and show a "Not compatible with Windows" status instead.
Which appears to be a blatant lie.


The SDK worked the last years before flawlessly, and apparently wasn't even changed since then. Actually, you can still download the SDK from Google's servers manually, and it will do it's job without problems.

With this strange behavior, it looks like Google simple wants to force developers to use their newer SDKs. And after all, no one is still using version 2.2 anymore, right? But looking closely into it, there are still around one million people using this version of Android! (source, source). Also, my customers are forced to use that version as well, so there is no way around it for me.

Update:: Looks like this was a bug in the SDK Manager, and Google has fixed it already. Nice!