Block engine demystified -> or how to create your own minecraft

[paulpach]

Hi,

I am writing a series of articles explaining the basics on how to write your own minecraft.

So far I have the following articles:

• Block engine demystified
• Block engine demystified II -> Out of sight, out of mind
• Block engine demystified III -> Do I have 16 fingers or what?
• Block engine demystified IV -> Packing lunch for millions
• Block engine demystified V -> The circle of life

These concepts are true, tried and applied in my game

Check out these video to see what it can produce


Here is a feature I added recently:


You can also try the game in your browser.

[Raziaar]

Very knowledgeable articles! I do not have time to read all of it before heading to work, but I did glance through.

I notice that you are rendering chunks in your game, as a single mesh to reduce draw calls. The problem I'm having in my game(not a block game), is how do you take that combined mesh and then pick off a piece of it when you decide it needs to be changed or removed, when a player clicks on it? The items I'm dealing with won't be blocks, but will be tiles which might have some more complex detail than six sides.

I basically create the array of my tiles, and then I know I should be doing some unity Mesh.CombineMeshes() operations to turn areas of my game board into a single mesh to reduce draw calls, but I don't know how to pick out the tiles I need from the combined mesh to change them, then recombine everything again.

[paulpach]

If you generate meshes out of your tiles, then my recommendation is to just regenerate the mesh for the chunk when there is a change. Given your seemingly simple constraints, performance should not be a problem for you.

In my game, consider what happens when a block changes, the light of all adjacent blocks might change (even of neighbor chunks), also blocks might be exposed to the air so new surfaces might need to be rendered. A single change might require changes in up to 8 chunks if you are dealing with blocks near a corner. Trying to modify the meshes for all these changes is just crazy talk. Plus, the slow part (generating the chunks) does not have to be executed again, so I just regenerate the meshes.

In your case, you don't seem to have infinite height, so up to 4 chunks might need to be re rendered.

I would not do Mesh.CombineMeshes with cubes since you are rendering significantly more triangles than you need (see 2nd article). If you do your own mesh, then your chunks could be much bigger which would reduce draw calls and increase performance

[Raziaar]

If you generate meshes out of your tiles, then my recommendation is to just regenerate the mesh for the chunk when there is a change. Given your seemingly simple constraints, performance should not be a problem for you.

In my game, consider what happens when a block changes, the light of all adjacent blocks might change (even of neighbor chunks), also blocks might be exposed to the air so new surfaces might need to be rendered. A single change might require changes in up to 8 chunks if you are dealing with blocks near a corner. Trying to modify the meshes for all these changes is just crazy talk. Plus, the slow part (generating the chunks) does not have to be executed again, so I just regenerate the meshes.

In your case, you don't seem to have infinite height, so up to 4 chunks might need to be re rendered.

I would not do Mesh.CombineMeshes with cubes since you are rendering significantly more triangles than you need (see 2nd article). If you do your own mesh, then your chunks could be much bigger which would reduce draw calls and increase performance

But if the mesh is all one single piece of geometry, how am I determining which tile is clicked? or am I just keeping the collider boxes in place so I can figure out which ones are clicked, change the mesh for them as needed(which won't be visible yet) and then regenerate the mesh(which will make all changes then visible?

[paulpach]

There are 2 ways you can do it:

The raycast function in unity can return a RaycastHit object.
The RaycastHit object has the point of the intersection. Assuming your tiles are all the same size it is very easy to calculate which block you hit from the intersection point.

In my implementation, I don't use unity colliders. To see what the player hits with the crosshair or with a touch, I use the algorithm described here. That algorithm is beautiful in its simplicity and efficiency, it is tailor made for a block engine.

[Raziaar]

There are 2 ways you can do it:

The raycast function in unity can return a RaycastHit object.
The RaycastHit object has the point of the intersection. Assuming your tiles are all the same size it is very easy to calculate which block you hit from the intersection point.

In my implementation, I don't use unity colliders. To see what the player hits with the crosshair or with a touch, I use the algorithm described here. That algorithm is beautiful in its simplicity and efficiency, it is tailor made for a block engine.

Thanks man, I'll digest the information.