What's your opinion of Minecraft?

[Love4Boobies]

Technically, Minecraft isn't voxels - it's textured cubes. A voxel has one colour, not 6 textured faces.

That's like saying Crysis doesn't technically use polygons because polygons don't have textures. Why did you assume that the voxels need to be the big building blocks that one uses in the game?

[Darwin]

It's a good game in my opinion. The storyline is fantastic!

[Brendan]

Hi,

Technically, Minecraft isn't voxels - it's textured cubes. A voxel has one colour, not 6 textured faces.

That's like saying Crysis doesn't technically use polygons because polygons don't have textures. Why did you assume that the voxels need to be the big building blocks that one uses in the game?

The word "Voxel" comes from "Volumetric Pixel". Basically a pixel is a colour in a 2D grid, and a voxel is a colour in a 3D grid. If a 2D game used tiles or sprites then you wouldn't try to pretend each tile or sprite was a pixel. In the same way, if a game uses textured cubes then you shouldn't try to pretend a textured cube is a voxel.

Also note that "textured cubes" isn't entirely correct either, because a lot of the blocks in Minecraft aren't cubes (torch, fence, stone slab, water/lava, doors, hatches, redstone, button, flower, etc). To be perfectly correct, it would be "arbitrary shapes built from textured polygons placed inside a 3D grid". Most 3D games would be "arbitrary shapes built from textured polygons placed in arbitrary ways", something that actually does use voxels would be "voxels in a 3D grid", and the new "point cloud" thing would be "coloured dots placed in arbitrary ways".


Cheers,

Brendan

[Love4Boobies]

Sigh. To clarify things, the little cubes that make up this axe are voxels (for people not familiar with voxels, they can have any shape):



On the other hand, this tree trunk is not a single voxel:



Voxels go into the object grid, objects go into the world grid. This is how it works.

[m35]

Sigh. To clarify things, the little cubes that make up this axe are voxels (for people not familiar with voxels, they can have any shape):

In terms of memory storage, the axe is not composed of smaller voxels, it's just a predefined object. You can't actually alter 'voxels' of the size of the cubes composing the axe.

[m35]

Your own interest clouds your judgment.

That makes a Troll +1, and a Hypocrisy +1.

That doesn't mean ye olde timewaster here doesn't think Minecraft can't be improved, but I also know that the game as is is good for many hours of gameplay (heck, it has already beaten LoZ in that regard - I assume you prefer that kind of game?)

Just because you don't agree with me doesn't make me a troll. And just because I happen to have an unpopular opinion doesn't make me a troll. And where's the hypocrisy? I would only be a hypocrite if I said the game couldn't be improved. Instead, I can see through my own personal dislike for this particular game's design and am even willing to try my own hand at improving it, at least at a technical level.

Minecraft doesn't have depth, realism, or very much strategy. It's as if it tries to take a middle ground and not accomplish anything. I like many types of sandbox style games from Simcity, Civilization, to Grand theft auto. All have their own share of weaknesses but they compensate for it by being strong in one specific aspect.

Dwarffortress is better than minecraft, but it's also a disgrace to gameplay. No ability to conquer, expand, or do really any offensive actions. And the economic system of the game is also embarrassingly limited and artificial feeling.

[m35]

Hi,

Technically, Minecraft isn't voxels - it's textured cubes. A voxel has one colour, not 6 textured faces.

For Minecraft, each block has a type, a generic data value (depends on block type), and some lighting related values. The blocks are grouped into "16 * 16 * 128 block" chunks. If you assume 16-bits per block, then one chunk is "16/8 * 16 * 16 * 128 = 64 KiB". There'd also be other information (more lighting stuff, biome data, etc) so let's round this up to 70 KiB. One chunk covers a 16 meter * 16 meter area of the world.

The world isn't all in memory at the same time. Chunks are loaded on demand. Only the chunks near the player (or near each player for SMP) must be in memory (but more may be in memory - e.g. cached). If there's a 9 * 9 grid of chunks around the player (so you can see a distance of about 72 meters around you) then it's "9 * 9 * 70 KiB = about 5.5 MiB". Of course you'd want to cache a much larger area around the player. If the world itself is about 5 Km square, then you'd have about 312 * 312 chunks, and it'll cost you about 6.5 GiB of disk space. With only 1 GiB of RAM you won't be able to cache all that.

For rendering, I think it uses OpenGL "display lists", where there's one display list per chunk. The main bottleneck is probably caused by the dynamic lighting - each time any light source changes any effected display lists need to be regenerated (which I'd imagine would be very expensive for things like dawn and dusk).

Then there's the texture data and data for models, data for "entities" (chests, animals, monsters, etc), the overhead of Java, etc. All of that probably costs a few hundred MiB; giving memory usage from "about 200 MiB" to "how much can you cache".

While all of this is "good", I'd do it differently. If they didn't use Java then it could probably be done with a minimum requirement of about 50 MiB of RAM. Minecraft is also "single-threaded", but it should be easy to use multiple threads (and multiple CPUs) to improve performance. The world is randomly generated, but they store generated chunks even if they haven't been modified - if you generate chunks fast enough (using a "seed" value in a way that allows the chunk to be exactly the same if it's re-generated again) then you'd only need to store chunks if/when something in them has been changed. In the same way, you could only store the differences between the world and the randomly generated data (rather than storing the entire chunk's data if anything in the chunk changed). That could slash the disk space requirements and disk IO overhead by a massive amount (but wouldn't help RAM usage or CPU load). You could also store the data in RAM as run-length-encoded vertical columns of data and slash the amount of RAM needed for storing blocks.

With all of those changes, you could probably afford to generate the terrain as true voxel data. For example, with 1/16 meter (or 62.5 mm square) voxels the same "9 * 9 chunk" area around the player would be an 864 * 864 grid of run length encoded columns. If each column costs an average of 30 bytes, then it'd work out to 21 MiB. If the player could only change "16 * 16 voxel" blocks then disk space usage would still be minimal - you'd randomly generate the terrain data, then use the "modified blocks" data (where the "block type" is used to find the voxel data for that block) and super-impose the modifications onto the the randomly generated terrain data.

Of course then you'd need to redesign the rendering to suit - with voxel data like that, you couldn't afford to have 3 polygons per voxel and let OpenGL render it (like you can with much larger blocks). If the camera always points towards the horizon, then you can just draw scaled vertical strips (keeping track of "top" and "bottom" as you do it) and it'd be reasonably fast (much slower than Doom where rendering stops as soon as the first wall is hit, but still fast enough for modern hardware). This has the same restriction that Doom had though - as soon as you let the player look up or down, the vertical strips in the game are no longer perpendicular to the camera and rendering becomes a massive problem. Doom never solved this issue - they designed levels so they're "relatively flat" so that the inability to look up/down didn't become a "game play problem", and made it so that for projectiles (e.g. bullets) the player didn't have to bother aiming up/down because the game calculated elevation. You couldn't do that for a game like Minecraft because you can't make sure everything is relatively flat. If you allow the player to look up or down then you need to solve the rendering problem, and while I believe it would be possible to solve it in a "fast enough" way, it'd probably take me a few months of research ("hypothesis -> prototype - > benchmark" and repeat) to figure out how fast it can be done (and if it actually can be done "fast enough" in practice).


Cheers,

Brendan

Great reply, as always. The idea of storing only the modified blocks is a great one.

[MasterLee]

Have a look at the following project:
http://sourceforge.net/projects/sauerbratencmed/
Sauerbraten with minecraft level loader and integrated circuit simulator.

[DJAlexem]

Have a look at the following project:
http://sourceforge.net/projects/sauerbratencmed/
Sauerbraten with minecraft level loader and integrated circuit simulator.

Cool, I have minecraft and have to say that the 1.8 update is gonna be pretty sick, i havent played it in a while cause of bored and dads time limites on the pc it sucks but i also Mix music and program and upload youtube vids so its pretty hard to do everything now...

but anyway, i think Notch is one of the best Java games programmers so far, any agreements? (otherwise go to hell.)

[VolTeK]

and dads time limites on the pc

Buy your own then. I sit in front of 3 monitors and program for 1/3 of my day. (No im not bragging most of it consists of coming up with designs in my software).

And why should you be limited?
Its alot better then going out and getting someone pregnate (Accidently.)

(otherwise go to hell.)

I hate notch. Then again, I hate games. Doesnt mean i cant work on a graphics engine and tools however.

[m35]

(otherwise go to hell.)

May you burn in the fire of a thousand suns.

[MDM]

Wow yikes!

So you have several interesting problems with writing a minecraft like program (I'm not saying minecraft couldn't have been written better, it could have if it was written in better languages using stronger computer science techniques). You have a fairly advanced 3 dimensional noise function that you have to develop that not only creates block positions but also block types concurrent to biome typology, depth, and surrounding blocks. You have to have an efficient file saving/reading system for reading and writing the world without lag. You have to use RAM very efficiently as the amount of blocks that are in a given range of vision is exponential. You have the problem of massive real time culling and draw call efficiency. You can't easily conjoin the cubes into a single mesh depending on material since it's a dynamic environment. You then have some easier challenges such as fast physics engines for red stone simulation, block gravity (for sand and what have you), and water simulation. You have a dynamic rain system that needs to be very efficient as well as pay attention to covering as to provide a somewhat realistic rain. You have rotating weather that uses complex noise algorithms with probability functions relating to the biome and previous/current weather. You have a surprisingly complex smooth lighting/shading algorithms. You have to handle AI efficiently as well (not that the AI is overly complex). One of the issues with the AI is you have to also build 3 dimensional noise algorithms based on biome and weather for deciding spawning positions of various animals. Some animals have the ability to migrate, which has to be stored/simulated accurately on and off screen.

As for the gameplay itself, while it is by no means complex, it is quite arguably the most dynamic gameplay of almost any game.

[DJAlexem]

Buy your own then. I sit in front of 3 monitors and program for 1/3 of my day.

I don't have that much money, as much as id love 3 monitors and ur knowledge (merged with mine cause i luv what i know), its not happening anytime soon.

Its alot better then going out and getting someone pregnate

Well, I have a gf, although it might be at least 7 more months before that happens (im 15 xD)

Accidently.

Condoms.

[Gigasoft]

but anyway, i think Notch is one of the best Java games programmers so far, any agreements? (otherwise go to hell.)

You are not in a legal position to require us to go to hell. I am covered under the blood of Jesus Christ, who died on the cross for our sins. He will be the arbitrator of that.

[DJAlexem]

You are not in a legal position to require us to go to hell.

There's a legal position for that?!?

Anyway, has anyone seen the 1.8 update pre-release? that looks so awesome, endermen are freaky..