After playing minecraft...

First time I've seen it, but looks like very nice work!

 

When it comes to actually building a world, there's not much in the way of tutorials or anything because it's not a very clean science. The gist of it is you learn how to create 3d perlin noise or use some existing code (like libnoise), and then spend many many countless hours (blindly) tweaking, combining, and adjusting different layers of noise until you come out with a world generator that produces a somewhat satisfactory result. There's no real shortcut, you're basically messing with random noise you come out with something that resembles what you want out of it.

 

I seart for man, who can make generator for my game. Who can plese pm me.

 

I'm searching for this man...to sell him...to other man....

 

You have a infinity world generator with mesh optimisation? If this true pm me please)

 

Wikened does make a good point tho. While, sure, it's not a exact science... Like anything in the world of computers, it can be explained by breaking down the various processes into simple steps. I studied code examples posted here for weeks before I realized I'm just going to have to study C# a lot more, because no one takes time to explain how their code works. I've got the basic concept down... Noise is the backbone that makes the procedural generation possible... But no one goes into how the noise is converted into a mesh, a critical step. I've seen Alex talk about how he does it, but it's not something a beginner would understand. I would love to see a practical example of how to generate noise, followed by an example of how to apply that noise "mesh generation". We aren't asking for a shortcut... We just want a example. No lights or shaders, no special features, no extra block types... Just noise generation and then a example of how to turn that noise into blocks.

 

Totally agree with you. If any one make this it would be great. Becouse understand complete code with no comments is very difficult

 

The problem with a "basic" example for infinite generation is you have to go into details about how your "chunk" system works to be infinite in 2 or 3 dimensions. There are plenty of ways to do this. They're all gone over somewhere in the thread... you just have to tinker with whichever you want to use yourself.

If you look through the thread, its basically a long tutorial on how to create a whole minecraft world. Basic ideas are at the beginning, while lighting and fancy blocks are discussed later on. Creating the block mesh and noise generation are both discussed fairly early on.

Basic idea:
2D noise to create a height map. With 3D noise set any number above a certain threshold to air. Now you have your block array.

For each face on each block in the array, check if there is a block next to it. If there is, you don't need to draw that face. If there isn't, add the four vertices from that face to the vertex buffer.

 

You make it sound simple. Maybe it is, but I'm still having trouble wrapping my head around it without a proper example. The ideas that are "all gone over somewhere in the thread..." Are basically fragments of ideas coming from people who have thought about this quite a bit and have experience with height maps and other coding projects. To someone just getting started on a project like this, none of it makes very much sense. Instead of giving us a "basic idea", why not create a basic example with some basic comments in the code? It doesn't even have to be infinite... A single 128X128X128 or 256X256X256 chunk would be perfect for this type of tutorial.

Something like this would make a lot of people happy:

A compact example consisting of the following elements-
1. A commented example of noise generation.
2. A commented example of the noise being converted into a mesh.
3. A example project showing the commented code in action.

That's it!

 

I get what you are saying. I had no real working grasp of the basics when I started this thread and the Minepackage project. Talking with others and looking at their code helped me understand the fundamentals. Until someone creates the documentation...sorry, you are going to just have to download the many samples out there and figure it out.

Frankly, it seems that just making the documentation you are asking for is more difficult than actually creating the project itself. Many projects have started down this road and stalled (mine did), but getting people to actually document it is like...heck, apparently a very difficult thing to do. I tried documenting some things, but I didn't necessarily document all of it. And personally, I think using forums as a place to store knowledge is crazy, but I'm also not volunteering to document this stuff myself

And also...when you talk about a basic example...I don't know how well that would work. I could create a basic example for the mesh generation. But this entire project itself relies on many systems being in place.
For example...noise generation. Fine. Caves...hmmm gotta add a little more. And now mesh gen. A little more on top of that. Lighting...a little more on top of that. Landscape elements like trees and such...a little more. Woah...performance is bad. Hmmm now let's talk multihreading. What about AI?

You're asking for a book on how to create a minecraft style world from start to finish. If I did that personally...I'd be selling it, not giving it away

I wouldn't mind contributing -some- to a well organized effort to document this process and its systems, as long as the goal is not to necessarily spew out working code, but to explain how the various systems work. If someone else wants to actually put down complete code, fine The problem is, everyone has slightly different ways to implement most systems, and who is to say which is best for which project? Also...I wouldn't be doing it alone, it would have to be a group/community effort.

Here is the wiki I had for minepackage. Not complete by any means.
http://sourceforge.net/apps/mediawiki/minepackage/index.php?title=Game_Systems

Mostly...it is a place for rambling and talking about how to do things like spotlights and colored lighting and such. I didn't even have notes on terrain gen. But still...it's mostly talking bout the systems, not the implementation.

[edited]. I'm working on a separate project that is pretty much taking up all of my spare time.

 

I won't argue that making a entire minecraft style engine complete with documentation would be a monumental undertaking. XD I don't think anyone would argue that. From reading this thread it's easy to see that when you really start getting into it, there are many complications involved and in the end, you will probably have to rewrite your code several times to get the kind of structure you want.

I just find it fascinating that no one has made a quick example of the basics. To people who have been working on this for a while, the mere idea of turning noise into a mesh is elementary, as you have already moved on to more advanced concepts like "How do I add objects and different layers of strata? How do I properly shade this mesh? How do I calculate light distribution?". But to people who are just getting started, it's a essential step in understanding the process behind it and a barrier from understanding the more advanced concepts.

Eventually I, once I get better at C# and figure out how everything works, would be happy to make such an example... People who have already mastered these basic concepts would make quick work of such a task. But ultimately, it's up to them if they want to preform an act of charity for less experienced game makers.

EDIT:
Ah, you make a excellent point about documentation in that everyone's project is slightly different. But from what I can see, all of them use some form of noise and then turn that noise into a mesh. It's this fundamental concept that a lot of us are having trouble grasping.

 

I think that as long as your are looking for the basic approach to the game systems, most should be very similar. I mean asking for simple blocks instead of sloped or 'noisy' ones. Basic block lighting instead of smooth/gradient lighting.

Is it the noise generation you are having difficulty with, or the mesh generation from that noise? Or both?

 

Well, the idea of noise generation seems easy enough. It seems like you could take something as simple as a sine wave and turn into repeating, rolling hills. That would be really boring tho, thus the need for more complex noise like Perlin or Simplex. What really gets me is the noise to mesh conversion. I have a very mild understanding of how it works, the idea of separating air and solids is easy enough to understand. It's just... Hard to reverse engineer what others have done, especially when they have already gone well beyond that first step. Further complicating things, everyone has a different way of doing it, so it's hard to identify what sections of code are relevant to only that function. Like you said... As the projects advance, many systems get tied in, clouding and obscuring how it works.

This guy wrote a AWESOME tutorial for explaining the overall concepts behind things....
http://accidentalnoise.sourceforge.net/minecraftworlds.html

But I'm left scratching my head, with no way to migrate that knowledge/code into Unity. Beezir's example at the beginning of the thread is the simplest working example I've been able to find, but I'm once again stuck, because it's virtually un-commented and very confusing. There are 4 block types in Beezir's project, but I can't for the life of me isolate the code that turns them into a mesh, or even what separates them for that matter. In more complex projects, functions are separated into many scripts, which doesn't seem to make things any easier.

So, I've given up on the idea of reverse engineering. I'm just reading C# books and practicing until I get the necessary skill to write my own system from scratch. I was more playing devils advocate for the random people asking for help in this thread.

 

Don't get me wrong though... I still think it would be FREAKING AWESOME if someone made a brief tutorial on converting noise to meshes, along with a working example to get your hands dirty with. And I don't think I would be alone...

 

1 UP))

 

There is no "noise to mesh" conversion going on at all. First you set up how you want the noise to be calculated. Next you place blocks where the noise is above or below a certain number (noise goes from 0 to 1). The mesh is made by seeing which blocks are in the array, not by the noise.

 

Excuse me, "noise to blocks to mesh". XD Further demonstrating the need for an example.

 

Noise-->Block
(Use noiselib for noise)
2D perlin noise- Create heightmap
If height < heightmap val, block = full, else block = air
3D perlin noise- If value > (some threshold), block = air

You have a 3D array of blocks now...

Block-->Mesh
Iterate all blocks
Iterate all faces on blocks
If air intersects the selected block face, you need to draw it. Add the verts from the block face to your vertex buffer.


You have a mesh!

 

It seems like you are over simplifying things quite a bit. "If value > (some threshold), block = air" is very ambiguous to me, lol how do you determine that threshold? Do you just start with block 0,0,0, check if solid or air, then move on to block 0,0,1, over and over until the entire chunk is checked? Not to sound stupid, but how do you actually check if it's solid or air?

Since you put it like that, it seems easy enough to check for solid blocks once you have an array, then draw on the sides that touch air. But making that array seems a bit confusing to me. How many variables do you store per block? Like, the x,y,z, solid or air? And, what's a good way of handling multiple small chunks?

I'm so making a commented example project after I get this down...

 

But that is the easiest part. You should see perlin noise and simplex noise as a density function, not as a noise function. They take 2 or more input parameters and give back a value between 0 and 1. e.g. float d = perlin2d(x,y)

Now to determine if it is solid we say that everything with a value greater then 0.5 is solid. Now we can generate an array containing the solid and air blocks simply by comparing the noise function output to our defined value. If we later decide that there is too much air, we can adjust that value to 0.4 or lower. The exact value to choose, is different for every project and terrain generation.

 

Yeah, I think Zerot is right there. When I did my terrain, I used the noise values as a height. So if my maximum height for the world was 128 blocks, and I got a noise value at 0,0 for .5, that meant the terrain height at 0,0 was 64 (.5 * 128). From there on down to height 0, I set the blocks to dirt. I then called another noise function to determine if there was a cave or not. Density. Type of dirt.

As far as the array...personally, I'd just create a 3 dimensional array for each chunk, where a chunk is say...32x32x128 blocks. Some people use a 1 dimensional array and figure out the block position themselves. Which runs a little faster...but you should get the easiest thing you can working first, then move on to optimization and such AFTER it works.

Also...when generating my mesh, I checked each block. If it was air, I tested the surrounding blocks and drew those faces that touched my block. If it was solid, I moved on. But whatever works eh?

 

if you use the 2d function in a 3d game the best way to use it, is as a heightmap. For a 2d game(like terraria) you can use it as a density function. A 3d function in a 3d world can be best used as a density function(though you can do with it whatever you want).

For some nice terrain generation, you might want to combine multiple noise functions. Like using a simple 2d heightmap for the base terrain(which will exclude overhangs) and then use a 3d density function for the caves.

 

Thanks for your replies jc_lvngstn and Zerot, I'm starting to understand how noise works a lot better now. The density analogy helps a lot. Also, I think I get how the array should work now too. Hmm... So what's a efficient way of storing the block variables, something like this?

Block 1: 0,0,1, a
Block 2: 0,0,0, s
Block 3: 0,0,-1, s
*a = air, s = solid

And, wow, how does that work? Say you have a 16x16x16 chunk and each block has 4 variables, does that mean you have to store 16384 variables per chunk?! This is going to get complicated. For a game that uses more then one block type, wouldn't you need a 5th variable too?

EDIT, wait, no, you could just expand the key to different block types, like a for air, d for dirt, r for rock, etc. That way you could keep it down to 4 variables right?

 

paulp , start a great blog with tutorials here: http://www.blocksters.com/node/57
If we want more, just register on his site and add your comment))

 

You're pretty much correct. But you don't need to store block coordinates, just use the array indices.
In my code, I had a chunk class.
The chunk class had a 3d byte array:
byte[,,] blockData = new byte[32,32,128] or something like that.

so if dirt = 1, stone = 2, and sand = 3:
blockData[0,0,0]=2 would set the block in the CHUNK at 0,0,0 to stone.

When you generate your mesh, you draw the sides of the solid blocks. This was something I didn't get at first, being new to game dev, was how to create the chunk mesh from the block data.

Seems to me this is an area that really needs documenting. No promises, but maybe this weekend I can type something up.

@HeadHunter Thanks for the link, but while he does go over some mechanics, those posts seem to be about optimization. I think people truly need in-depth, complete documentation on the various systems.

 

Do you think a block engine should be available on Unity's Asset Store? Check that:

http://forum.unity3d.com/threads/123463-Block-engiine-gt-Make-your-own-minecraft.-Would-you-buy

 

You mean, do I think people should sell a block engine made with Unity? Heck yeah. I wish paulp all the success in the world there. If we had a fully functional block engine with most of the bells and whistles, people could actually start MAKING GAMES with it instead of recreating the wheel over and omg over and over again.

I want to see what people create, not watch the 1000th person struggle to recreate the engine itself. No offense to those who wish to do this for the sheer pleasure of it...but I suspect many people want to create something with the engine. Otherwise...why are we even using Unity for our development, instead of making our own game engines? Bleah!

Not to mention, and powerful block engine would be a big selling point for Unity.

 

I particularly think you guys optimize too much. As master Knuth said:

"Premature optimization is the root of all evil in programming"

We need a working block engine world, from start to end, with basic features like dig/build, terrain generation, basic lighting, basic water (minecraft's) and basic multiplayer (smartfox preferably). After that you can optimize as you wish. No need of advanced water simulations, cave generations, super lighting or other non-basic features. Some code optimizations are indeed needed, but not the premature ones.

If someone solve these basic elements and sell it on asset store I wouldn't be surprised to see a blog post like that: http://blogs.unity3d.com/2011/04/27/congratulations-to-asset-store-top-seller-brady-wright/.

 

With my engine, I've got enough optimization to make it run so I can play around with it. One thing that I wanted badly in mine was auto-deformation and I've finally got that working. Next up is light generation. I'm shooting for the skies on this one though. I want my lighting to be similar to how Terraria does it. Theirs is constantly updated so you can do things like hold torches while walking and have things light up as you walk.

The way I'm storing my light/colors is by having a HUGE array of colors. I've made a new color class that holds a byte for color instead of a float. The array looks like this...

Code (csharp):

1.  
2. ColorI lights[x,y,z][face][vertex, layer]
3.  

To stop it from storing every vertex of every block, even non-existing ones, I refresh the array every time I regenerate the mesh. The way I've set it up so far is that each vertex has 3 layers.

Layer 1 - Main Block Color
Layer 2 - Custom Color (mainly lighting)
Layer 3 - Ambient Light

I have another function that combines all the colors and puts them in a regular Color array for the mesh to use.

Also..
I've found out that using List<T>.Contains was causing quite a bit of lag so I've switched to checking booleans that are part of the Chunk class now.

 

This is great!

Got a simple test chunk working, using his tutorial:
http://unitycoder.com/upload/demos/DummyCraft1/

 

Cool) Can you please share your code? And then every one can look how to implement this tutorial)

 

yes, i'll do that this weekend.

also hoping to get ideas how to improve the system,
now with 32x32x32 chunk im at 2fps, when modifying the blocks..
(as it creates the complete chunk again on every change..Oo)

 

Couldn't agree more, there are some great engines out there and it seems silly repeating the same task over and over again. The focus should be, as you said, making games.

paulp was promoting a nifty package in that poll... But it became apparent that the sections I was interested in, paulp is locking up in binary form, which made it considerably less attractive to me. He talked about offering a "full version" with the complete source code at a higher price point... Holding my breath.

 

That kinda threw me off at first, but really...it makes sense. My biggest concern would be how flexible the dll is. Like...could I specify different chunk sizes, visible map size, depths, etc etc.
My only other suggestions would be 1) include some good and bad simple ai people can use with their own creatures, and 2) have a plugin system for world decorations like trees and such.

 

Ideas are coming . Check out my next post. I suspect the next post after that will be more helpful to you as I go over how blocks should be stored.

However, until your share your code it is difficult to tell what is going on.

As for the people wanting to license my engine, It is coming too. I do want to clean up a little, refactor a couple of things to make a good API, and document the code first.

 

^ yeah..thanks, have to make a new version with that,
as for this first one I just made it as a simple function..

test version source is now here,
http://unitycoder.com/blog/2012/02/15/dummy-craft-chunk-renderer-js/

 

Cool) Thanks. But i always have error when try to remove block:

 

hmm..havent had that error here, just tested again and it works (on 3.5)
did you change anything in the code?

 

No i didnt change anithing. But i use Unity 3.4.2

 

You have to do some stuff mgear forgot to mention on the camera you need an line renderer (that gave me an error but was easy to solve). Maybe its the same for you, oh and create a material for the mesh that may cause an error too.

Good job mgear.

 

No This is another error. I create a line renderer and other stuff before launch it.

 

New version here. Terrain now loads in under 3 seconds in my non gamer computer.

What I was doing before was to have a rectangular view area. But this was wasteful because chunks near the corners of the view area were too far away for the player to see. Now, the view area is spherical around the player which has less chunks without affecting the minimum view distance. When you look towards the corner there are less chunks in the view frustum so draw calls stay much more consistent regardless of where you look.

 

Hey I've been using this package for a learning experiment, right now I'm working on torches, but when I attach a Light source to the player it doesn't light up any of the blocks that I look at! I would really love to find out how to fix this and if possible the shader for it!

 

What package?

 

Guess he taks about the unity miner package.

 

With the help of HeadHunter, we managed to get my engine working in android.

Check out the mobile version here or the web version here

and check here for what is new:
http://www.blocksters.com/node/64

It is surreal to have this thing run in my phone after all this time.

 

Wow, that's fantastic! I don't have an Android to check it myself, but the screenshots look great!

I'm curious, what did you have to sacrifice/optimize aside from texture quality to get it to run on a phone?

 

• reduce view distance
• write several version of shader. From fastest to prettiest. User can pick midgame
• had to drop specular light ( gold) . But every other effect works
• pack blocks in 4 bytes struct instead of 8. No feature dropped because of it
• texture size was decreased
• a chicken was sacrificed in an altar

 

thx its really good

 

A bit of self-promotion

I added 2 features which I think haven't been discussed in this thread:

• Blockception (having 2 blocks per voxel). It gives the player more options to build, and the results are more realistic (grass can't stop water from flowing). This also means that you have to store double the information.

This really helped a lot!​

• I managed to simulate dynamic sunlight with a surface shader. It's not as accurate as having a directional light, but closed areas aren't illuminated (with a directional light and no realtime shadows, some faces get lighted up when in a cave). The tricky bit is to determine which vertices are affected by the sunlight and which aren't.

Download link

Recommended options:
Shadows: Off
VSync: Off (faster loading)
Constrast Stretch: Off
Bloom: On
Block Lighting: Off
Sun Shafts: On
Depth of Field: On
FXAA: On
Chunk Speed: 4
Chunk Distance: 5++ (adjust according to PC)
Fog Distance: Off
Save All Chunks: enabled (faster loading)
Crosshair: On