OSDev.org

I think it's a blunder both technically and stylistically.

I'm pretty sure most of us, especially here, realize that a game like Minecraft should be playable on something like an i386... and not require over a gigabyte of RAM and a GHz+ processor as it currently does.

And the gameplay: conceptually, a 2D version of Minecraft wouldn't be much different than a text editor where you're free to play with ascii characters.

1. Do you realize the amount of data required to make up the virtual world represented? Lets say you hold in RAM something like, what, 500 blocks in each direction? Thats 785000 just for the surface blocks. The environment has depth, so yes, it is going to be RAM intensive

2. Do you realize how much work 3D rendering requires? Particularly of this kind of environment? Minecraft is ridiculously dynamic; say you can see 200 blocks, thats 126k blocks just to consider for rendering the terrain. Frustum culling will eradicate about 3/4ths of them; being as half will be behind the camera and 1/8th in the region between the edge of the screen and the near clipping plane in each direction.

So, now we are at 31400 blocks to render. Here is the first rule of graphics programming: Batch, batch, batch. Every batch takes a certain amount of CPU time; that amount is constant for any given quantity of geometry. So, this is no trivial task; I don't know how Minecraft's renderer works, but if the debug output is any indication serious thought went into batching up the geometry well, as would be necessary if you wanted something of this complexity to actually render faster than 1fps. I imagine a lot of thought went into culling invisible geometry (not a simple task) also.

The gameplay is perhaps the greatest thing about Minecraft though: It is ridiculously simple. It is easily learnable... and yet from that simplicity you can do things of enormous complexity.

And you know what? I say this as someone who has never played the game.

Well, then I issue you a challenge: Code a game that is similar and runs on an i386. I'd love to see it.

And the gameplay: conceptually, a 2D version of Minecraft wouldn't be much different than a text editor where you're free to play with ascii characters.

Ok, what? Have you even played the game? Firstly, its 3D, so your argument doesn't make sense. Secondly, ......no! I can't even respond to this argument! It doesn't make sense! Its like "tide goes in, tide goes out..."

You are a troll.

-JL

P.S. I love the game, its really fun. Especially if you play it like trying to survive in a hostile world. Which is the default. And is nothing like moving ascii characters around. I'm gonna laugh about this thread with my friends later.

Owen wrote:1. Do you realize the amount of data required to make up the virtual world represented? Lets say you hold in RAM something like, what, 500 blocks in each direction? Thats 785000 just for the surface blocks. The environment has depth, so yes, it is going to be RAM intensive

It doesn't and shouldn't all need to be in RAM at once.

2. Do you realize how much work 3D rendering requires?

It's just rendering of cubes. Do you not remember DOOM? Of course a 386 version of Minecraft won't be able to run in modern display resolutions (or even have the same field of view depths) but I don't think doing it all in mode 13h would be that much of a stretch. My main point was that Minecraft shouldn't require any where near the amount of resources it takes.

The gameplay is perhaps the greatest thing about Minecraft though: It is ridiculously simple. It is easily learnable... and yet from that simplicity you can do things of enormous complexity.

With a text editor you can make any infinite number of complex structures. With Microsoft Word, the capabilities aren't even comprehensible!

piranha wrote:Well, then I issue you a challenge: Code a game that is similar and runs on an i386. I'd love to see it.

I think it would be a fun project. And intend to work on something like this as time allows. No promises on deadlines.

Ok, what? Have you even played the game? Firstly, its 3D, so your argument doesn't make sense.

Which is why I said 2d equivalent...

Secondly, ......no! I can't even respond to this argument! It doesn't make sense! Its like "tide goes in, tide goes out..."

You are a troll.

...

P.S. I love the game, its really fun. Especially if you play it like trying to survive in a hostile world. Which is the default. And is nothing like moving ascii characters around. I'm gonna laugh about this thread with my friends later.

Your own interest clouds your judgment. I have played it. And the AI leaves much to be desired.

Well, the AI isn't the point. More effort was put into the building of objects and etc than was put into making creepers target you better. And yes, my interest does cloud my judgement, but you seem to be pretty adamantly disliking it...why? It's a fun game, seems to be put together well, and is interesting to play.

Which is why I said 2d equivalent...

But why give the argument at all? The 2D equivalent of a flight simulator would be similar to moving a block around on screen, yet you must agree that a flight simulator is vastly more powerful than such a thing. The 2D equivalent of anything is much less than the 3D thing itself. Its a completely pointless argument.

I think it would be a fun project. And intend to work on something like this as time allows. No promises on deadlines.

Good luck.

...

dotdotdot

With a text editor you can make any infinite number of complex structures. With Microsoft Word, the capabilities aren't even comprehensible!

Yes, but are you building anything cool? Unless its ascii art, no. In minecraft, you can actually build interesting structures, and create elaborate things. It's obvious I like it, so I defend it. But it also obvious you hate it, so you will try to find reasons to hate it that are rational, other than "I don't like this cause I don't". If you made it so that not all of the chunks of 500 blocks in every direction were in memory all the time, you'd get horrible lag, and the world would look terrible.

-JL

m35 wrote:It's just rendering of cubes. Do you not remember DOOM? Of course a 386 version of Minecraft won't be able to run in modern display resolutions (or even have the same field of view depths) but I don't think doing it all in mode 13h would be that much of a stretch. My main point was that Minecraft shouldn't require any where near the amount of resources it takes.

Doom used an entirely different technique known as ray casting (not to be confused with ray tracing). Ray casting engines essentially create 2D games that are rendered to look 3D-like---the world can't be more complicated than what you see on the map (e.g., you can't go under a bridge, you can't look up/down; there is no height, it's all an illusion---even Doom's elevator things).

Minecraft uses voxels, which are conceptually different from polygons. Voxel-based engines are much more powerful (e.g., you can poke a structure in one place and make just a tiny hole or can move sand around to build a sand castle, just like in the real world) but take up a lot of memory, which is why you can't usually make them look very good if you have a big world. Voxels are usually used in medicine and the sciences when precision is important.

piranha wrote:If you made it so that not all of the chunks of 500 blocks in every direction were in memory all the time, you'd get horrible lag, and the world would look terrible.

500 blocks wouldn't be possible, but with a 320x200 resolution, you wouldn't be able to see that far anyways.

215 blocks (16 types) in every direction could fit in 4mb, even before optimizations: ((((215^3))*3/8 = 3.7Mb

This can be optimized further by the fact that movement occurs more on the xy plane with less movement on the z axis. So a rectangle of blocks would probably buy more performance than keeping a cube of blocks in RAM. The dimensions of the volume could be determined dynamically during runtime based on a user's play-style.

Another thing that could buy performance is storing above ground blocks in an address table instead of wasting memory storing all the empty air blocks. The definition of 'above ground' would have to be adaptable of course to adjust for large changes in the environment.

Love4Boobies wrote:

m35 wrote:It's just rendering of cubes. Do you not remember DOOM? Of course a 386 version of Minecraft won't be able to run in modern display resolutions (or even have the same field of view depths) but I don't think doing it all in mode 13h would be that much of a stretch. My main point was that Minecraft shouldn't require any where near the amount of resources it takes.

Doom used an entirely different technique known as ray casting (not to be confused with ray tracing). Ray casting engines essentially create 2D games that are rendered to look 3D-like---the world can't be more complicated than what you see on the map (e.g., you can't go under a bridge, you can't look up/down; there is no height, it's all an illusion---even Doom's elevator things).

Minecraft uses voxels, which are conceptually different from polygons. Voxel-based engines are much more powerful (e.g., you can poke a structure in one place and make just a tiny hole or can move sand around to build a sand castle, just like in the real world) but take up a lot of memory, which is why you can't usually make them look very good if you have a big world. Voxels are usually used in medicine and the sciences when precision is important.

I see. But it seems like computationally this wouldn't be that difficult (given the quality of the graphics, a lack of textures wouldn't be a huge loss to gameplay), it's just a memory management problem.

Historically, when were the first voxel-based games created?

m35 wrote:I see. But it seems like computationally this wouldn't be that difficult (given the quality of the graphics, a lack of textures wouldn't be a huge loss to gameplay), it's just a memory management problem.

That's true, although animation is not particularly easy to do either (but it can be done). Unlimited Detail is a state of the art voxel-based engine.

They claim to have found a way to make voxels take up small amounts of memory but their demonstrations don't show that; the structures are highly repetitive even though their marketing departament came up with an excuse for that.

m35 wrote:Historically, when were the first voxel-based games created?

I don't know but they were never very popular. Not many voxel-based games exist.

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

m35 wrote:I think it's a blunder both technically and stylistically.

I'm pretty sure most of us, especially here, realize that a game like Minecraft should be playable on something like an i386... and not require over a gigabyte of RAM and a GHz+ processor as it currently does.

With that amount of machine poor one could run Sauerbraten engine. Which looks many times better.

m35 wrote:And the gameplay: conceptually, a 2D version of Minecraft wouldn't be much different than a text editor where you're free to play with ascii characters.

A 2D version would be an really poor version of Clonk.

m35 wrote: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?)

MasterLee wrote:

m35 wrote:I think it's a blunder both technically and stylistically.

I'm pretty sure most of us, especially here, realize that a game like Minecraft should be playable on something like an i386... and not require over a gigabyte of RAM and a GHz+ processor as it currently does.

With that amount of machine poor one could run Sauerbraten engine. Which looks many times better.

At runtime, how much of the Sauerbraten world changes? Very little (i.e. powerups disappear and reappear, players move about, but most of the geometry stays still)

At runtime, how much of the Minecraft world can change? Lots. The player is free to pretty much modify any bit(s) of it they want.

Ergo, they are extremely dissimilar problems. The Saurbraten geometry is already broken down (by the map editor) into near perfect sized chunks for the graphics card. The Minecraft geometry is broken into much smaller chunks, which the game has to batch manually in order to get into sizes that are appropriate for the GPU.

Key rule: Dynamic geometry hurts! If its staitic, you can perform all sorts of optimizations on it in order to reduce the scale of the problem. If its dynamic, then any such optimizations have to be far, far faster. Quake map editors could afford to spend ages crunching BSP visibility. In real time, such things are harder.

And anyway, the graphical style is intentional. Really, what is the main interest in Minecraft? I'd say its building crazy contraptions and/or buildings. So, what should the focus be on? What the player has built.

Now, unless you made the building much more complex (and we are entering a wholly different ballgame here) then its hard to imagine a graphical design for the game which would maintain its most important feature: simplicify!

Owen wrote:

MasterLee wrote:

m35 wrote:I think it's a blunder both technically and stylistically.

I'm pretty sure most of us, especially here, realize that a game like Minecraft should be playable on something like an i386... and not require over a gigabyte of RAM and a GHz+ processor as it currently does.

With that amount of machine poor one could run Sauerbraten engine. Which looks many times better.

At runtime, how much of the Sauerbraten world changes? Very little (i.e. powerups disappear and reappear, players move about, but most of the geometry stays still)

At runtime, how much of the Minecraft world can change? Lots. The player is free to pretty much modify any bit(s) of it they want.

Thats depends on the actual game and the game mode. In coopedit the world change i usally greater as in deathmatch mode. Also in Platinum Arts Sandbox the world is usually greater as in Sauerbraten(Game) or Red Eclipse.

Owen wrote: Now, unless you made the building much more complex (and we are entering a wholly different ballgame here) then its hard to imagine a graphical design for the game which would maintain its most important feature: simplicify!

Now they are completely different In Sauerbraten (and Minecraft) you work on CUBE2 where at least in Second Life you work with geometric primitives.