I had my own "fire" incident, this game should be used to teach kids about the dangers of the naked flame! There were no trees near my house so I planted lots all quite close together.
(can you see where this is going?)
I was beset by monsters so taking a leaf from others I built bonfires all around the grounds of my house to fend them off. Sadly one of them was a little too close to my "orchard" and you can guess the rest ...
The AI was written so quickly it's still at a very early stage and it's amazing how many funny events spring out of it. For example, I think the fires just reduce the chance of a nearby monster spawn (or maybe they don't even do that). The first night after the fires went up all I could hear were zombies screaming and cooking. In the morning there were monster drops everywhere. Later all I could hear were cows, ducks and sheep screaming as they blundered into the fires and burnt to death, leaving meat strewn everywhere. Then there are cows paddling around in the water looking quite upset, cows up on cliff tops throwing themselves onto the rocks below, sheep trapped in some bizarre mating ritual with trees, etc.
What happens with the spawn mechanics, AFAIK is that the light from the fire DOES in fact prevent hostile NPCs from spawning. However, the range really isn't that far, and hostile NPCs can wander into a lighted area - only light from the sun kills zombies, not light from fire. So what is happening to you is that NPCs are spawning in the dark areas, and wandering into the light areas.
Also note that some NPCs do not die at night, such as creepers (the guys that explode) and spiders (which are not hostile during the day unless you attack them first, or they are already attacking you when daybreak comes).
Posted: Wed Sep 29, 2010 9:22 am Post subject: Minecrack!
Bought this... OMG I can't stop playing it!!!
There are a number of elements that really worked for me:
* Firstly, the ability to build anything out of blocks
* Crafting tools, cosmetic stuff etc
* Day-night cycle - running back to your shelter for the night
* That feeling of cosiness and safety during the night whilst you're crafting stuff in your lair and hearing groans and moans outside
* Embellishing and expanding your lair
* Exploring the sprawling mines
Someone at my workplace has hosted a server and we're pretty much terraforming a whole world.
Joined: 28 Oct 2006 Posts: 95 Location: Oxford, UK
Posted: Wed Sep 29, 2010 4:15 pm Post subject:
Boingboing posted a video last night from a guy who's built a (fully functional) 16-bit ALU in Minecraft and is planning to add the necessary memory and other bits to turn it into a 'proper' computer. Currently he has to walk in among the registers and set every bit individually with a torch before he can ask it to add two numbers together - and there aren't many computers you can say that for!
Joined: 25 Nov 2004 Posts: 476 Location: Karlsruhe, Germany
Posted: Fri Dec 31, 2010 1:06 am Post subject:
I finally started playing Minecraft about 4 weeks ago. Really nice game. A little hard, though, at least in its default difficulty setting.
What actually interested me more than the game itself was how the levels/worlds are stored and how they are rendered. Fortunately the Minecraft wiki has a good breakdown of the level/chunk format.
Being a programmer I made a Minecraft world viewer over the past 2 weeks just for fun. Not only for fun, of course, but also to learn something.
My goal was to load the whole world (=134 million blocks) into RAM and render it. Well, loading the world was not too big of a problem. Rendering the whole world will probably not be possible, even with optimization.
Currently I render only block faces that can possibly be seen by the player: Faces that are next to air or next to a translucent block. This sums up to around 720 KB of vertex/color/texturecoord/normal data per chunk (16x16x128 blocks). UPDATE: The following sentence is wrong:As a world consists of 64x64 of those chunks this would use about 3 gigabytes of GPU memory.The world (theoretically) is infinite in all 4 directions. So calculating its memory footprint on the GPU does not actually make sense.
Maybe with some more (simple) optimization -- I still render too many water blocks/faces, for example -- I could reach around 600 KB per chunk, but that wouldn't help much, I guess. With really good optimization maybe 300 KB may be possible. But still...
Performance-wise rendering the whole level is not that bad, though. I once rendered about 36x36 chunks (without color and normal information to save memory) and still was able to have around 20fps on a >3 year old ATI graphics card.
The fun started when I wanted the rendering to look good. So I looked into deferred rendering (FBOs in OpenGL), depth of field and Screen Ambient Occlusion (SSAO), all done with vertex and pixel shaders.
How to do depth of field was explained in a developer diary entry by one of the Anno 1404 developers. Quite simple, really. Basically only uses the depth buffer to decide how far a pixel is away from the camera. There are 2 renderings of the current scene, one sharp and the other one blurred. Both pixel of these renderings are mixed together, based on the depth information. (The farther a pixel is away from the screen, the more of the blurred image is used.)
For SSAO I looked at the SSAOFilter in JMonkey (Java 3D Engine), which uses the code from this Gamedev article. The results are for from perfect, though, and only really work when looking at the world from above. It falls apart as soon as you walk below trees or through narrow passages as they are common in Minecraft.
These Starcraft 2 slides from Siggraph are quite interesting. They cover some (but not all) of the issues I still face with depth of view and SSAO. Currently, for example, all polygons that are next to space/void (=background) have a blur halo around them, even when they are directly in front of the camera and are not blurred themselves. The slides explain this problem and how to work around it.
In hindsight I really should have written some kind of diary while programming the world viewer, to show the progress and problems I encountered. But, well, maybe too late already.
For your entertainment here are some screenshots from the first rendering (1 chunk) and the current state of the renderer:
First rendering after 2 evenings of work:
More or less current renderings:
I really learned a lot about OpenGL and shaders. All in all I had a lot of fun and probably will have more for the next few days.
What I'm going to implement next:
- Translucency for translucent tiles like leaves and water. (I'm not quite sure if it's still necessary to order the geometry for transparency or if this can be avoided using shaders.)
- Lighting. (Sun/Moon and probably some simple "radiosity" stuff, as it is done in the original Minecraft: Dark dungeons, lighted by torches etc.)
- Only rendering chunks that can be seen by the player. (Frustum culling.)
Currently the renderer can only render blocks, so no ladders, torches, flowers etc. are supported. But I don't know if I want to do implements/create proper models for these special blocks. You can see placeholders for flowers in the last screenshot, for example.
I almost forgot to mention:
Currently when rendering 11x11 chunks (theoretically 4 mio. blocks) I get a framerate of between 90 and 110 fps using a 3 years old graphics card.
Last edited by Slyh on Thu Jan 06, 2011 3:55 pm; edited 1 time in total
Joined: 25 Nov 2004 Posts: 476 Location: Karlsruhe, Germany
Posted: Fri Dec 31, 2010 1:38 pm Post subject:
The ambient occlusion works really great for simple blocks like the dirt and grass blocks seen in the last screenshot. No color changes are visible when moving towards them or parellel to them. Only when faces with shadows move near the border of the window the shadow effect is reduced/lost.
Look at the second sand block from the right. In the first image it has normal ambient shadow, in the second image it has nearly lost all shadow. That's because the shader does not know anything about the geometry and only calculates the occlusion shadow from the depth and normal buffers. As these buffers are only as big as the image itself the algorithm can no longer calculate the shadow properly near the eges of the window.
This can be fixed by rendering an image that is a little bigger than the screen/window itself offscreen and then cut away the border areas.
Also, in the scene shown above when you move to the left or right, you can notice shadow halos around most edges. But that's hardly noticeable, as the halos are still \"projecteed\" onto terrain blocks around the edge.
The effect is a lot more noticeable inside narrow dungeons or around tree leave blocks. It's hardly visible in still images, but when moving/flying around or past trees, these shadow halos look really strange and wrong, as they appear to be in the air around the leaves.
I'm now wondering if the really irritating halo effect inside dungeons is only visible because of the lost shadow effect described above. Maybe I should try to render a slightly larger image next, to see this can improve SSAO results.
Joined: 25 Nov 2004 Posts: 476 Location: Karlsruhe, Germany
Posted: Thu Jan 06, 2011 5:03 pm Post subject:
Thought I might post a little update.
First of all I have to correct myself. Above I said that the world is limited to 64x64 chunks. That was wrong. The world actually is infinite in all 4 directions. (As long as x and y fit into a 32 bit signed integer, that is. :-))
I didn't add very much to the renderer since my last posting. I only added the following:
- Leaf rendering and rendering of other quasi-translucent elements
- Very simple water rendering, with real translucency
- Shadow mapping
Leaves and others \"translucent\" elements are now rendered using alpha masking. Alpha masking does not actually render translucency, i.e. foreground color is not mixed with colors from the background. Instead pixels are either rendered fully opaque or fully transparent (not rendered). The advantage of this approach over real translucency is that polygons don't have to be ordered before rendering so that farther away polygons are rendered first.
Code-wise this it's only one simple if-statement in the fragment shader:
if (alphaMasking && colorFromTexture.a == 0)
Water has real translucency, though, and to avoid having to order polygons, a separate render pass was added for water rendering. So I now first render only terrain and then render only water (with its translucency) over the already renderer terrain. This works because the depth buffer is not cleared between both renderings.
This way it was possible to avoid any polygon ordering. It's done the same way in the original Minecraft for the same reason.
Of course, looking at water through water, for example when looking through a waterfall and at a sea still does not work right with this approach.
Finally, I did some shadow mapping with the usual approach: Render the scene from the light's point of view -- but only the depth buffer -- then render the scene regularly and calculate for each rendered pixel the position in the shadow map (depth buffer) and look if the currently rendered point lies behind the point in the shadow map or in front of it. When the point is behind it is in shadow and rendered darker.
That was a lot easier than I thought it would be. Before fragment shaders were available it somehow seemed more complicated to me. But now it only takes up 5 (simple) lines in the fragment shader and some lines of code on the Java side where the modelview and projection matrices of the light's point of view are read from OpenGL.
I currently render into 1024x1024 wide shadow map, which is really low resolution for such a huge level. This results in a lot of shadow artifacts at edges. In the above image you can see that not all of the face of the sand mount in the foreground is in shadow and that the shadow on the ground has strange edges. I added an outline to the blocks and where the real shadow position would be so you can see more easily what I mean.
Rendering into a 4096x4096 shadow map helps a bit, but not much and uses a lot more memory. I tried to find out what games currently use for shadow mapping. It seems most modern games use multiple shadow maps, one map for polygons near the player/viewer and 1 to 3 maps for polygons that are farther away. So the objects near the player have nice crisp shadows and farther away objects have lower-res shadows, which still looks good.
I'm not sure if I want to do this right now, though.
Some more artifacts for you viewing displeasure. ;-) Both faces facing the player should be completely in shadow.
Shadow maps are a performance killer, by the way, simply because the scene has to be rendered two times, one time from the light's point of view and one from the player/viewer's point of view. The frame rate drops to about 60%.
I wonder how the guy from Overgrowth does shadowing mapping. It looks **** great!
And back to minecraft proper, they recently hit one million sales.
That's a "1" followed by 6 zeros.
If we presume that all of those were sold at the alpha price, that means Notch has grossed 10 million euros. I really wonder how rich he is now. I just hope that his newly created company is successful. It's one thing to create a miraculously wonderful hit game out of nowhere. It's another thing entirely to do it a second and third time.
Joined: 14 Oct 2002 Posts: 4107 Location: Sheffield, UK
Posted: Fri Jan 14, 2011 10:03 am Post subject:
Yes, it's astounding, I've talked to him a bit and he's a really nice guy - hence him being open about the work they are doing and how much money it's making, he's not being boastful just open. It'll be interesting to see how the game develops and what he brings out next, a lot of people are saying it's a fluke. I wish things like this could be achieved more regularly, it would make living as an indie far more popular and practical (mainstream sucks).
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum