Wedding Weekend!

Hi everyone! I’m getting married to ez tomorrow, and I thought we’d celebrate by giving one free copy of Minecraft to everyone who buys the game!

How does it work, you ask?

Well, if you buy a copy of the game (not a gift code), you get a free gift code added to your account. You can see the gift codes you have by going to
Tell your spouse/lover/friend/acquaintance/stranger go to and enter the code, and within minutes you’ll both be punching trees and installing texture packs together.

Have a great weekend, everybody!

(ps, we are aware of the typo in the graphics, but it’s too expensive to fix now)

Bethesda are suing us, here’s the full story!

A lot of people want more details about what is going on, so here is everything I know:

First of all, I love Bethesda. I assume this nonsense is partly just their lawyers being lawyers, and a result of trademark law being the way it is.

About half a year ago, our lawyers recommended us to register “Minecraft” as a trademark, so we did. I had voted against it initially, but we did it anyway. Better safe than sorry, and all that. At the same time, we also applied for “Scrolls”, the new game we’re working on. We knew of no similarly named games, and we had even googled it to make sure. I’m not even sure if you CAN trademark individual words, like “Scrolls”, but we sent in the application anyway.

(Disclosure: We’ve enforced the trademark for Minecraft once, when there was a minecraft clone on iOS, using our name. People were emailing me saying our iOS version was buggy and bad, so we asked them to change the name of their game, and they did.)

A while later, out of the blue, we got contacted by Bethesda’s lawyers. They wanted to know more about the “Scrolls” trademark we were applying for, and claimed it conflicted with their existing trademark “The Elder Scrolls”. I agree that the word “Scrolls” is part of that trademark, but as a gamer, I have never ever considered that series of (very good) role playing games to be about scrolls in any way, nor was that ever the focal point of neither their marketing nor the public image.
The implication that you could own the right to all individual words within a trademark is also a bit scary. We looked things up and realized they didn’t have much of a case, but we still took it seriously. Nothing about Scrolls is meant to in any way derive from or allude to their games. We suggested a compromise where we’d agree to never put any words in front of “Scrolls”, and instead call sequels and other things something along the lines of “Scrolls – The Banana Expansion”. I’m not sure if they ever got back to us with a reply to this.

Today, I got a 15 page letter from some Swedish lawyer firm, saying they demand us to stop using the name Scrolls, that they will sue us (and have already paid the fee to the Swedish court), and that they demand a pile of money up front before the legal process has even started.

I assume this is all some more or less automated response to us applying for the trademark. I sincerely hope Bethesda isn’t pulling a Tim Langdell.

“But Notch, it’s NOT a scam!”

I’ve been getting a bunch of feedback that my last blog post is wrong for various reasons, and I’d just like to say that I would absolutely LOVE to be proven wrong. Being wrong is awesome, that’s how you learn.

If you want to read my reasoning behind various assumptions, click “read more”.

Why I assume it’s voxels and not point clouds:

* Voxels store only the information about each point, and their positions are implicit in the location of where the voxel is stored. Point cloud data stores both the information about each point and the position of each point.
* They mention “64 atoms per cubic millimeter”, which is 4*4*4 points per mm^2. While it’s possible they only refer to the sampling frequency for turning polygonal structures into point data, the numbers are just too round for me to ignore as a programmer.
* All repeated structures in the world are all facing the same direction. To me, that means they aren’t able to easily rotate them arbitrarily.

About the size calculation:

* I was trying to show that there was no way there was that much UNIQUE data in the world, and that everything had to be made up of repeated chunks.
* One byte per voxel is way lower than the raw data you’d need. In reality, you’d probably want to track at least 24 bits of color and eight bits of normal vector data per voxel. That’s four times as much data. It’s quite possible you’d want to track even more data.
* If the data compresses down to 1%, it would still be 1 700 three-terrabyte hard drives of data at one byte of raw data per voxel.

Animated voxels:

* Holy crap, people sent me videos of this actually being done!
* I was wrong! 😀
* (But please note that just that single animated character runs at 36 fps)

Why it’s a scam:

* They pretend like they’re doing something new and unique, but in reality a lot of people are researching this. There are a lot of known draw-backs to doing this.
* They refuse to address the known flaws. They don’t show non-repeated architecture, they don’t show animation, they don’t show rotated geometry, and they don’t show dynamic lighting.
* They invent new terminology and use superlatives and plenty of unverifiable claims.
* They say it’s a “search algorithm”. That’s just semantics to confuse the issue. Sparse voxel octrees is a search algorithm to do very fast ray casting in a voxel space.
* They seem to be doing some very impressive voxel rendering stuff, which could absolutely be used to make very interesting games, but it’s not as great as they claim it is. The only reason I can see for them misrepresenting it this bad is that I assume they’re looking for funding and/or to get bought up.

If these guys were being honest with the drawbacks and weaknesses of their system, I’d be their biggest fan. As it is now, it’s almost like they’re trying NOT to be trustworthy.

All this said, voxels are amazing. So is raytracing and raycasting. As computers get more powerful, and storage gets faster and cheaper, we will see amazing things happen.

And a final word to the engineers who worked on this: Great job, I am impressed! But please tell your marketing department to stop lying. 😉

It’s a scam!

Perhaps you’ve seen the videos about some groundbreaking “unlimited detail” rendering technology? If not, check it out here, then get back to this post:

Well, it is a scam.

They made a voxel renderer, probably based on sparse voxel octrees. That’s cool and all, but.. To quote the video, the island in the video is one km^2. Let’s assume a modest island height of just eight meters, and we end up with 0.008 km^3. At 64 atoms per cubic millimeter (four per millimeter), that is a total of 512 000 000 000 000 000 atoms. If each voxel is made up of one byte of data, that is a total of 512 petabytes of information, or about 170 000 three-terrabyte harddrives full of information. In reality, you will need way more than just one byte of data per voxel to do colors and lighting, and the island is probably way taller than just eight meters, so that estimate is very optimistic.

So obviously, it’s not made up of that many unique voxels.

In the video, you can make up loads of repeated structured, all roughly the same size. Sparse voxel octrees work great for this, as you don’t need to have unique data in each leaf node, but can reference the same data repeatedly (at fixed intervals) with great speed and memory efficiency. This explains how they can have that much data, but it also shows one of the biggest weaknesses of their engine.

Another weakness is that voxels are horrible for doing animation, because there is no current fast algorithms for deforming a voxel cloud based on a skeletal mesh, and if you do keyframe animation, you end up with a LOT of data. It’s possible to rotate, scale and translate individual chunks of voxel data to do simple animation (imagine one chunk for the upper arm, one for the lower, one for the torso, and so on), but it’s not going to look as nice as polygon based animated characters do.

It’s a very pretty and very impressive piece of technology, but they’re carefully avoiding to mention any of the drawbacks, and they’re pretending like what they’re doing is something new and impressive. In reality, it’s been done several times before.

There’s the very impressive looking Atomontage Engine:

Ken Silverman (the guy who wrote the Build engine, used in Duke Nukem 3D) has been working on a voxel engine called Voxlap, which is the basis for Voxelstein 3d:

And there’s more:

They’re hyping this as something new and revolutionary because they want funding. It’s a scam. Don’t get excited.

Or, more correctly, get excited about voxels, but not about the snake oil salesmen.

The psychology of the reticle and the feeling of control

This blog post contains extensive spoilers about a new mob in the adventure update. Don’t click “read more” unless you want spoilers!

Fear is one of the easiest emotions to evoke, but doing so in a way that doesn’t frustrate or fatigue the player is more difficult. I find this fascinating. What parts of fear are fun, and what parts aren’t fun?

One of the biggest game design decisions in Minecraft is that all (well, most) negative things that affect the world or the player should happen near the player, and be clear to the player. That’s why creepers only explode near players, and that’s why fires stopped spreading indefinitely. This is somewhat related to my dislike of mazes in game design, where the player has no way of knowing or figuring out before hand what decision is the correct decision. Don’t penalize the player for things they can’t control.

Last weekend, I started working on a new mob because I was frustrated with the slow progress on some town code I was writing, and for some reason I decided to make yet another creepy one. It’s dark, it has long and narrow limbs, moves very slowly, and will pick up blocks and move them around. I wanted this to be a mob you only saw in the distance and a mob you’d be afraid of, but when I playtested it, it mostly felt like a regular zombie. There’s was a distinct mismatch between looking creepy and not actually playing creepy. When I made it move faster towards the player when attacking, and deal more damage, it got more difficult and I started respecting it, but it never felt creepy or scary.

So I thought some about what “creepy” actually is, and it’s more about trying to avoid something from happening than it is about actually having that thing happen. If you know something bad can happen if you do the wrong thing, you will start thinking about your actions, and that might make things more scary.

So I made it passive until you looked straight at it. And that was scary. Suddenly you could walk up to these looking beasts (they’re three meters tall) and watch them as they moved their blocks around, but as soon as you happened to look straight at them, they’d attack. And by “straight at them”, I mean putting the reticle on top of them. You can keep them visible on screen and actually look straight at them in real life, but as soon as your in game character looks straight at them, boom.

Still, that was more scary than creepy. It’s like a jump scare in a movie. You know it might happen at any time, and when it happens you freak out a bit. I wanted something a bit more psychological. So to really drive home the point of looking at them being bad, I made the Endermen freeze and turn towards you when you look at them. As long as you look straight at them, they stand perfectly still and look straight at you. As soon as you look away, they will run (very fast) towards you.

And they teleport. If they’re too far away to reach you in a short period of time, they will teleport about once per second. They try to make sure they always teleport to somewhere you can see, as I don’t want to confuse the player as to what is happening.

When they attack, you know it’s your fault. When you happen to look at one, you can keep looking at it to figure out how to deal with it, but you know it WILL reach you very fast once you stop looking at it.

And that, my friends, is creepy. Possibly too creepy.

Sharing an interesting email

I briefly talked to the crazy engineers over at Bat Country Entertainment about mods that alter the height limit in Minecraft. Ryan send me this interesting email about what different tradeoffs there are, and his experiences working with it:

Very cool! Off the top of my head, here’s a list of the main points:

Implications behind changing height:

– Memory Implications: Due to the way chunks are architected internally, the only relatively-easy way of increasing level height is to double it. As a result, memory usage can spiral out of control very quickly when increasing the number of bits available to the Y axis. A somewhat short-sighted view would be to point out that this is wholly manageable in SSP, but pragmatically, SMP is already a hornet’s nest when it comes to RAM usage, and the only way to increase the level height would be to neatly double the memory footprint. Ouch!

– CPU Implications: Chunk terrain generation occurs in pieces on the X/Z plane, but expects the chunk to be fully populated along the Y axis, from bedrock to sky. To be fair, much of this can be mitigated by the fact that any terrain above a certain cutoff can be assumed to be completely air, and any terrain below a certain cutoff can be assumed to be completely stone, thus eliminating the need for temperature / humidity / biome calculations far down in the level or high up in the level. Nonetheless, it’s still a cache-thrashing memory-fill operation. Worse still, due to the fact that subterranean features are populated per-chunk, to maintain a consistent distribution of ore you would need to double the number of calls made to any given feature generator as well for each doubling of the Y axis. While this is relatively cheap for things like ore, it’s eclipsed by the idea that cave generation would need to occur along the entire Y axis, and being a recursive function, this has the potential to get very costly very quickly.

– Storage Implications: Anything stored in memory needs to be serialized to disk and read back from disk. Given the fact that in SSP, the number-one performance killer – even on my beastly computer – is disk I/O, it would be a highly questionable idea to double the amount of data that needs to be written out to disk. I’m not completely sure if chunks are gzipped before being written to disk, or if that only occurs to chunks when transmitted over the network, but if they are, this simply robs from Peter to pay Paul – it mitigates the disk I/O issue while increasing the enormity of the CPU issue.

– Network Implications: On SMP, Chunks need to be sent to many more people many times more often than in SSP. It can be taken for granted, from a client’s perspective, just how much data needs to be shoved around by the server, and although network packets are gzipped, it’s still an additional networking load, and still an additional CPU load as well.

Regarding changing the level height, it was “easy” to the extent that it took me around 4 hours yesterday morning to do it, but only because I’ve been poking around the engine internals since January and have been mentally keeping track of all of the assumptions in the code on exactly that topic. From top to bottom:

– Search through the codebase for « 11 and « 7, replace with « 12 and « 8 as necessary.
– Search through the codebase for 128, this will hit the majority of places that assume the map height as being 128, such as tile height checks.
– When changing the above locations, save yourself a recompile and make sure to change any variables from bytes to shorts or ints if you’re increasing them past 128. Being a C++ engineer, I keep forgetting that everything is implied as signed in Java.
– Search through the codebase for 127, this will hit the remainder of places that assume the map height as being 128.
– Search through the codebase for 64 and 63, this will hit the places that assume sea level is at 64, as well as Iron’s ore generator height cutoff. Personally, I dialed sea level up to 96 from 64, rather than fully double it up to 128, in order to have 32 additional tiles’ worth of water height, but have an entire 96 additional tiles’ worth of land height.
– Fix up the level feature generators for Redstone, diamond, gold et al.
– Visually grep through all of the level feature generator classes, doubling the RNG baseline and spread for each one.
– Change a few instances of 32768 to 65536 to accommodate 16*256*16 rather than 16*128*16.
– I’m not sure how much of this is a result of JAD and how much of it is actual code, but there are a few instances of “char whatever = ‘\200’;” in the MCP codebase, change it to a short or int containing 256 instead of 128.

I have to say that the game was *remarkably* performant with the Y height pushed up to 256. I imagine 512 might not be too bad on my beast of a machine, either, though 1024 would be pushing it. That said, one of my short-term “just for fun” goals is to see if I can’t get the Nether to populate from 0-127, the main world from 128-255, your Sky dimension from 256-383, and then that one group of modders’ new dimension, the Aether, from 384-511. That would be epic.

Additionally, there’s a mod that some guy made that re-works chunks to be 16x16x16 (it appears), but I’m rather nonplused by it. The bug list is as long as my arm, and it doesn’t actually rescale any of the terrain-generation features, so you don’t get neat things like this:

As a result, I’m in the process of just trying to re-do what he did on my own. I’m filling all chunks above Y=256 entirely with air, filling all chunks below 0 with stone, manually invoking the cave generator, and theoretically things should just work. In principle, theory is a flimsy thing to go on, and to that end I’ve been chasing down bugs for the past 4-5 hours. At present I’m able to get in-game, but the chunks are horribly mis-arranged, so I suspect I’ve missed an important hashing function somewhere, since that would also explain why it’s spitting out reams of “Wrong location!” exceptions that it’s spitting out whenever it tries to spawn animals – the level provider is providing the wrong chunk.


– R

Minecraft Beta 1.7.3

Bug fixes, bug fixes and bug fixes.

– Corrected a block duplication bug when using pistons
– Corrected a redstone torch duplication bug when using pistons
– Corrected a client crash when placing a sign in front of the piston, powering the piston and then removing the block beneath the sign
– Ice blocks are now pushed without causing water streams breaking everything
– Booster rails are no longer being powered magically without a power source
– Pistons connected to the end of a piston-transistor via redstone are now properly closed when the power goes out
– Doors no longer create purple particles
– Hacking clients can no longer edit texts of placed signs in multiplayer
– Changed so that paintings pushed by pistons will pop off