Minecraft mode

A lot of people wanted to customize their headquarter in the game, so last weekend, I experimented a bit and programmed a Minecraft style mode for the game:

It actually works nicely, but is of course limited to the buildings. For now, once finished, this mode will likely only exist for the fun of it, but it could be possible to extend it to make more sense gameplay wise. But let's see.


I'm used to getting strange software reviews on various app stores. But I think Steam reviews are one level ahead. I'm confused for example about this one:

Is this good? Is it bad? I don't know. But he played it for 23 hours, so it shouldn't be that bad. Right? Hm.

TV will be dead soon

Just had to explain to an upset child that on TV, you cannot "watch again" or "watch another episode" or watch something different. Yes, on TV, you have to watch what they are sending, and when they are sending it. Being used to Youtube / Netflix / Amazon Prime Video and similar really makes it difficult to understand how TV is still in business. And while I had to explain how TV works to this child, I noticed that at least when that generation is older, TV will be dead.

CopperCube 5.5

Finally, I pushed out a free update for CopperCube again, we are now at version 5.5. New features are:

There is also a new CopperCube website. It is responsive and minimal, and not very overloaded with information. I personally don't like that. For a 3D engine, I want detailed information, but it seems that people prefer this style now: Few shiny images, just very few lines of text, and that's it. At least all the information about CopperCube is still there, but now on the 'features' page. Let's see how this turns out. I'm looking forward to see what impact this has on sales and downloads.

Most Unity game ever!

I think this is the most funny review I received until now for PostCollapse:

Apparently that youtuber doesn't like the game, and he calls it the "Most Unity Suvival Game ever!". Ha :) That's especially funny since I'm one of the very, very few people out there which did this: I wrote nearly every line of code in my game from scratch, myself, in C++. Including the 3D engine. And sound engine. And collision detection. File System. Translation. Input handling. World generation. Hell, I even composed the music myself.

I'm interestingly not even mad, it is actually a bit entertaining :)

PostCollapse now on Steam

PostCollapse is now on Steam:

As early access, but available. Hope you like it!

Getting Feedback is difficult

Since the first day when I created software, I always wanted to have feedback from people, so that I could improve my software. That's one of the reasons why I started blogging back in 1998, when the term 'blog' didn't even exists. (I was working on an isometric diablo like game named 'Irrlicht' back then, which unfortunately was never finished).

I've learned that the average willingness of giving feedback voluntarily is very, very low. For example for every 100 readers of this blog, only 1 will post a comment. Driving this value up is possible, but telling the readers that you want feedback usually will not work. (But making some unusual claims or invalid statements will do this easily, usually.)

Until now, about 2000 people have downloaded the alpha demo of my game. You would expect that I already have at least 20 people giving me some insight on how to improve it. Interestingly, I only received 6 so far, of which 3 are angry that the price of the game is so high. (What!? It's just 9 euro!?)

Not sure what this means. Is this a good sign? Do people like the game, and they don't see any reason to complain? OR is it a bad sign? The game is so bad that they don't bother to deal with that at all? I have no idea.

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.


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


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.


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.


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.