After playing minecraft...

Pretty cool. For me, moving around is much too slow, but it looks cool.

Although this is such a `low resolution` game environment, I think in future there will be more games like this made of smaller and smaller blocks.

I don't know if your code does this already... but you should consider only modelling the surface of the game world. Don't store anything below the surface. Then when someone digs out a hole or whatever, you add to the surface model ie add a dent in it. Overall that has got to be more efficient for storage and display than having a full volume of blocks, many of which will never be seen.

 

man that lighting is REALLY good, the in game character is a little too fat though to get in a 1x1 cube area haha. and your rolling mountains are very realistic, though minecraft has a more cliff/steeper areas fantasy-like, but very cool so far.

 

I'm interested that moving was too slow for you, so far it seems like most have been pleased with performance. Was it while the engine was still drawing chunks? On my setup, that slows down the system until the map is generated, then my fps jumps back up.

Currently, the world is effectively an array of blocks, 512x512x128. With two bytes per blocks, this is about 66 megs...so really, that isn't so bad.
What's gobbling up memory is the mesh. Currently, I only create the meshes from the sides of the cube which are exposed to air. So...it really is just a mesh of the surface of the world, including underground caves.
I think the biggest optimization I could do is to completely get rid of the collision mesh. That would free up memory, but it would also mean having to create a custom character controller and collision handling. But, it would also mean I wouldn't have to create mesh faces for unlit cubes...something that could potentially free up a pretty nice chunk of memory also.

I just haven't had much luck with the custom character controller just yet, and right now, getting the infinite terrain generation in, a basic inventory, etc is a little higher priority.

 

I think he meant that character controller moved too slow. I was very happy with the performance on my integrated graphics card, the chunk gen seemed sufficiently fast too.

I assume you plan to split the terrain up into chunks like Minecraft? If you do please increase the vertical limit, 128 is simply not enough.

+1 for the whole get rid of collision mesh but focus on inventory and terrain gen thing.

 

I would think if just making a 'template' the inventory shouldn't be included or maybe included last, anybody can make an inventory, is this going to be a template for exactly like minecraft? or just the terrain gen?

I would say
water
random terrain every creation
save terrain to file
continuous terrain
better performance

 

Currently, it is split into chunks like minecraft.
I also plan, at some point (maybe now is as good a time as any) to split up the vertical depth into chunks also, instead of just being 128 blocks high. There doesn't appear to be that much memory overhead going 256 blocks deep, I tried it.

You could even have infinite terrain up and down. There are some...considerations with this though, with sunlight. Currently, the world is shallow enough so that if you are digging along the bottom of the world, and break into a shaft that goes straight up to the surface, it will immediately light your surrounding blocks due to sunlight coming down.
With deeper worlds...how high up do you check for each block that you dig, to see if sunlight has been exposed? 256? 1024? If you're very deep, and have never explored the chunks above (and exposed them to sunlight), and you climbed up the shaft, you would suddenly "pop" into sunlight when you did reach the surface.
Unless you wanted to make a minecraft clone where you were in the center of a planet, and never reached the surface. Boy, that would make things simpler.

Regardless...if I can knock down the memory usage, I wouldn't mind including a terrain generator in the package for much deeper worlds (would probably mean higher mountains and deeper ground).

 

Water was the first thing that made me realize I had to change my mesh generation/collision mesh approach.
Currently, the entire chunk mesh uses a texture atlas for its textures. Works great.
Except there's no way to tell it, hey for water...use a transparent shader, that moves. At least not in a straightforward way that I understand and implement.

Even if I get rid of the collision mesh altogether, and handle player movement depending on what type of block he is in (make him float in water), I still need to handle transparent textures, or textures that might flow. I don't see how having all meshes share a common texture atlas is going to allow for having some of those textures to be transparent, sliding or animating, at least not in a straightforward way. Sure, I could have something that modifies that particular texture in the atlas, shifting it...but that just doesn't seem as flexible to me.

So, what I will probably end up doing is, for each type of thing like water, lava, slime, whatever you want to add where it needs special materials and behavior, each chunk will have a separate mesh for that and material for that. I just don't know of a reasonable way to handle it being transparent and having a different behavior for the player than solid terrain does. So chunks will have a terrain mesh (solid ground/rocks, trees, etc) that uses a common texture atlas, and one or more fluid meshes that have their own unique materials.

And one of the key things about why and how I am doing this is, it may not be the -fastest- code, but I want it to be easy to understand and modify for your own. If you want to add a new type of tree to the landscapes, it's very easy. You don't have to go into the terrain generation and hack up the code that adds trees, breaking chunk lighting and cave generation in the process because it's all crammed in their together.

Instead, you just go and add a class that does nothing except look at the current location and decide if it's a good time and place to put your decoration, and then put it there. Fastest way possible? Most likely no. Fast enough? I think so. Easy to extend and understand for others? Yeah...I think so.

 

Very cool, makes sense.

as far as chunks go, wouldn't it make sense to split the first chunks into two categories
Main Chunk
Ground (mountains) Level = 64 blocks
Water (ocean) Level = 64 blocks

Decend Chunk
128 blocks under Main Chunk (underground)

Decend2 Chunk
128 blocks under Decend Chunk

Accend Chunk
128 blocks on top of Main Chunk (above ground)

Accend2 Chunk
128 blocks on top of Accend2 Chunk

Then split that into folder structures as well for quick access.
Instead of loading 256 blocks, you could say "if player is between 120th block of decend, and above 8th block of decend2, load all 256 blocks, otherwise, only load 128 blocks of the sector he is in"

as far as the lighting

"With deeper worlds...how high up do you check for each block that you dig, to see if sunlight has been exposed? 256? 1024? If you're very deep, and have never explored the chunks above (and exposed them to sunlight), and you climbed up the shaft, you would suddenly "pop" into sunlight when you did reach the surface."

I am a little confused on this, wouldn't the player still see sunlight at the top of the shaft?, just his surrounding blocks wouldn't be lit, but that makes sense if he can just a see a pinhead of light at the top.

 

Yes, the framerate is fine, what I meant was that moving around is too slow. It's like `walking speed` kinda, takes ages to get anywhere. I also find it annoying having to `jump` up the `steps` of blocks that are only 1 block high, which is practically all over the place. Maybe you should allow the player to automatically smoothly slide over 1-block-high steps?

I expect that using some fancy shaders you could do something like a screen-space terrain renderer which might be faster. Like, a raycaster.

Also how about some fractal interpolation of the block surface? ie it doesn't really get `stored`, you don't get to edit the fractal parts, but they add to the appearance of detail? And what happens if you start to use something like normal mapping, displacement mapping, etc, to roughen the blocks? Can you turn those square blocks into what looks like an irregular rocky surface?

 

I think the whole success of minecraft is that it is blocky, but a neat add-on would be ability to add slopes. Its not just for taking apart a mountainside its about building your own house out of what you just took from the mountain side. If building was much more complex I don't think it'd be as fun. Also if the blocks were smaller it wouldn't be much fun cuz it'd take you 4 1/2 days to build a simple house.

It would have to be done correctly though with trees, water etc. Don't add a slope if its water, don't add a slope if its trees, you COULD add a slope with water, I think it'd be pointless though.

Thats all my opinion though, as I think walking speed was fine. In the end its all preferences.

 

So, right now the idea with minecraft and my package so far is, the world is infinite is breadth, but only 128 blocks deep. Each chunk is made up of something like 16x16x128 blocks.
There's nothing to keep you from having the world made up of chunks that are 16x16x16 blocks, and then making the world 16 chunks deep (this would mean it would be 256 blocks deep total).

I'm not sure I understand your first point, about only loading chunks based on your depth. Wouldn't that effectively limit your view distance to 128 or 256 blocks high?


As far as the sunlight question...an important part of the lighting algorithm is a pass that lights all sunlit blocks in the chunks. A sunlit block is any empty block that is, well...visible from directly above if that makes sense.

This is important for spreading the light into darker areas, and also...if you ever want to have a day/night lighting cycle (something I actually wasn't planning on putting into the package, but I'm pretty sure I know how to do it), you have to identify sunlit blocks first since sunlit blocks and ones lit by them are affected by day/night changes. Blocks lit by artifical light (torches, lava) aren't affected by sunlight or the lack of it.

Anyway...when you dig into an area exposed by sunlight...the game sort of needs to know how far sunlight reaches down. All I was saying is, if your game has infinite depth...if you dig waaaay deep then across into a cave that extends to the surface...the game has to know if way above you, at some point, light actually would reach you. If you only look at the current chunk, and maybe a few chunks above, that may not be far enough up to reach the surface and "see" that sunlight would reach you.
In essence...looking up would always see dark, unless you were close enough to the surface or had explored the area above you to the surface.
Hope that makes sense, sorry if it's just confusing

 

Well, I'll be honest...I'm fairly new at game development. I think having a shader that could do some displacement would definitely be awesome. I've look at the shader stuff...and haven't had much luck really understanding it well enough to make anything useful.

I think marching cubes, to smooth out slopes and such, is a very good idea. Not only would it get rid of the blocky terrain, and make it easier to move around, but it would distinguish even more from the original minecraft (in a good way), thus making it stand more on its own.

Someone mentioned earlier that I should put this on GitHub. And other such as you self have definitely shown an interest in the project. I guess what I want is to get this starter package out in a form that is a good, solid foundation for people to take in their own directions. I'm trying to find the balance or line between providing a good basic starter package, and pulling others in to take it even further. I would absolutely love a serious group effort to take it even further, once the initial effort is done. But, while I've been programming for some years now, game development and this sort of thing is new to me.

 

crime scene OSX: I had a try with the latest version, started the webplayer, after three minutes of watching the colourwheel spinning, my left leg got hot and i had to kill the task.

 

Gahh you're right, didn't think about that one, and yes everything made sense you explain it very well... also your code is very easy to read doing great

I am not new to coding but very new to unity and I get about 90% of what is going on in the code.

 

That sounds awesome. So it seems like your intent is to allow others to build off of this engine? That would be quite amazing of you. Also, I'd be interested in working with you on your project if you are looking to put together a team. I'd definitely like to see what can be done with an engine like Minecraft.

 

I'm going to take a look at the startup performance. I should be able to improve that.

 

You could do what isometric games like Transport Tycoon Deluxe do for slopes, have a set of wedge primitives that define a slope (one corner high, 2 corners high, 3 corners high) and either replace or add on top of your normal block terrain with those pieces.

Also, I would be interested in more updates to your source code as well. I have the older ones, but this is an interesting project and fits well with my interests (procedural terrain, block based maps, infinite landscape). Although I'm going towards the Dwarf Fortress (3d person rts cam style, multiple mobs) route than Minecraft (which I do have and play as well )

 

Definitely the best way to go, super simple (compared to marching cubes), looks great, low resource requirements, the list goes on.



As for increasing the height limit...

If you break vertical space into multiple chunks you may want to think about falling. If you fall off of the top chunk and the terrain below you is in an unloaded chunk you may encounter some problems if you cant load chunks fast enough. I would suggest loading chunks in a sphere shaped pattern if you implement unlimited height and including a failsafe that sets Time.timeScale to 0 if you reach the bottom of the unloaded chunks, at least until enough new chunks are loaded.

 

I love the look of that landscape. I'll see what I can do If I can get it working pretty quick, I'll repost the code. Any tips or suggestions on the algorithm in the meantime would help it get done that much quicker.

There do appear to be special situations. I can see that in some situations, you create a top and bottom trangle for a "square". In others, you create a left and right triangle.
Or, maybe there's a smart way to just create triangles, and forget about squares. The current algorithm looks at the world as cubes between points. This may require a different way of looking at it.

Having a flat landscape is one thing...but we've got caves, overhangs...that may add some complexity.

 

I'd start just with the outdoors "top" layer, or limit it to only dirt blocks to begin with. Rock can stay blocky. Erosion will be the biggest cause and mostly from surface rain. After you've decided on the mechanism to use, you can move to a more comprehensive overhaul.

It might be useful to change your grid reference from block (or "face") based to vertex (corner) based. Been a while since I looked at your code so IDK but it would probably be a time consuming but one time conversion. It would make checking adjacent vertex heights quick. YMMV, just throwing out ideas.

Find a place online for your source code if you get a chance!

You're doing great work and this is by far the most interesting thread here. Keep it up!

 

Regarding an online home for the source...is there a difference between using something like Github instead of Sourceforge or somewhere else? I could always just put it in my dropbox, but it would be awesome to also have a discussion area.

 

Could it be that it was hanging? I can imagine quite some stuff which takes three minutes to calc on a Core i5 CPU but then again this is a lot of time as well.

@ITAmember
Oh, this looks nice.

 

on my fast computer at home it loads instantly, on my work computer, it hangs and says "do you want to wait, or quit application" and you say "wait", sometimes it pops up twice, but eventually the game loads.

 

I made an isometric tile engine like this back in the day using C++ and the Allegro library, I ended up just using a large switch statement to determine which tile to draw. The performance was acceptable because I could cache the tile type after the initial generation. And no, I don't have the code anymore. :/ This is in 2D of course so it's a bit different but the same principles should apply. You may be able to simply it slightly however by nesting if statements thanks to the whole mesh of triangles thing.

Perhaps just do the same thing upside down?

+1

I've been thinking about this and sourceforge would probably be best for this project. It has an integrated forum, which I think will be very important if you intend to have a large community involvement. A tacker, wiki, and blog further sweeten the deal. Github is more a place for strict development, it is not really intended for non-developer involvement. (In my opinion)

I've always enjoyed that kind of terrain, it's simple, dynamic, and visually appealing. This is from a 3rd person perspective though, first person might be a little strange.

 

Here's the latest source. It doesn't have the super cool awesome slopes, sorry

http://www.filefactory.com/file/b48a41e/n/MinePackage.unitypackage

And here is the web player:
http://dl.dropbox.com/u/5556115/WebPlayer/WebPlayer.html

It looks like SourceForge is the way to go, looks like it has everything I need. I need to look at what I can upload, and what would be restricted. Perhaps only my scripts for now.

Startup time should be much quicker also.

 

Looking really nice!

 

haha oh man you're rocking it dude, that world is amazing, doing very very good.

 

Very nice. I haven't had time to work through the code yet but is there any reason you are not seeding the random number generator? Every time I open up the web player I get the same terrain.

 

I'm about to switch to using libnoise, that should give me more control over terrain generation.

 

Ok, I've got a sourceforge site up. I'm brand new at this, so until I figure out what license to use, and get things organized...it mostly will be a place for discussion and the source for my C# scripts. If you want the entire project or web player access, it will have links to those.
But, I won't be using the gossip forum as my main discussion area, I think it's time for a dedicated home for the project. Let me know if you have any suggestions, comments, etc.
Thanks!

Site link:
http://minepackage.sourceforge.net/

 

heehhe very good just dig a hole and felt in a cave !!!!!
look at hte little hole at the top of teh screen

grats !

 

So any news on this projects?

 

yeah...he (jc_lvngstn) has a forum for it here: http://sourceforge.net/projects/minepackage/forums/forum/1314602
and he started a web page for the package here (but its just a place holder right now) http://www.minefoundations.com/

 

@Beezir when I try to replace my textures with point filtering the dont work...

 

Any chance of temporarily putting up the package file on the sourceforge site? The filefactory package keeps failing to complete when I download it.

 

I just used SVN to check out minepackage from SourceForge see "Code" section. Unity gave me grief while importing the project and it's assets. I got around the blah is missing issue by creating a cache folder in where you checked out the minecraft project.

Example: c:\Unity Projects\minepackage\Library\cache

 

Has there been any recent updates to this package?

 

This is absolutely incredible what is the etiquette for contributing to the script?

 

The project has stalled, but you can find the MinePackage site on sourceforge. I actually just refreshed the package source not long ago, you can download it from dropbox. As to why it's stalled...blame my short attention span, along with the massive challenges of networking with an infinite world and the dedication needed for the project. It's a good foundation and useful, but in need of polish for sure.

The means of adding unity gameobjects and blocky objects like trees and such to your scenes is slick, though.

 

Kudos for a very cool project indeed! I took a look at it a few months ago while playing Minecraft, and thinking about going down that route myself. I really enjoyed reading the through the daily posts you guys made back in 2010. Read like a fast paced novel, but with webplayer demos along the way.

 

This sounds cool could I use it to improve my Magix: Elementus prototype?



http://www.arowx.com/ld/mini26/

 

Guys, how do you calculate lighting on the edge of chunks?

There's a problem:


1. If we remove the red block, the sun light from above should go from one chunk to another several times. There are only two chunks on this picture but imagine if there were two more below and four behind. It would be eight chunks affected by removing just one simple block.

2. The red block is removed. Let's remove the green one. Now we have to recalculate lighting for the left chunk, and we should somehow remember that the left chunk also gets the light from the right chunk that actually may get this light from somewhere else.

I tried to bring light to my world, but everything became overcomplicated very soon.

 

I am wondering on how to place blocks. I was investigating into raycasts. I theorized perhaps you can get the face of the cube and then place the block depending on the face. I tried using triangleindex's but that doesn't help much. I was thinking of perhaps making a dictionary that stores the triangleindex's when the mesh is being created and puts a certain value telling which side they represent. I am using Beezer's example.

 

It can be calculated from RaycastHit's point and normal properties.

Code (csharp):

1. Vector3 center = new Vector3(Screen.width * .5f, Screen.height * .5f, 0);
2. Ray ray = Camera.main.ScreenPointToRay(center);
3. RaycastHit hit;
4. bool raycastResult = Physics.Raycast(ray, out hit, 30f);
5.  
6. if (raycastResult == false)
7. {
8.     return;
9. }
10.  
11. int x = Mathf.RoundToInt(hit.point.x - hit.normal.x / 2); // Minus for removing block or plus for adding block
12. int y = Mathf.RoundToInt(hit.point.y - hit.normal.y / 2); //
13. int z = Mathf.RoundToInt(hit.point.z - hit.normal.z / 2); //
14.  
15. Vector3 blockPosition = new Vector3(x, y, z);

 

It dosen't seem to be working quite right. But it's close. I will try and refine it. Thankyou.

 

I have been working for a while on smooth realtime world generation, and found out that the biggest lags happen when I assign meshes to mesh colliders. Although the assignments don't take much time individually, in the moments when the game creates a bunch of new meshes, one mesh per frame or per second or so, it feels jerky. These lags are inevitable because collider's properties can't be changed in background threads, and the more complex the meshes are, the more noticeable are the lags.

As long as colliders don't require meshes with uvs, normals and colors, one can create two meshes: one visible, with all these stuff; and one simple, just for physics. That simple mesh can consist of much less triangles and still work as good as the complex one. Here are my results:

16x16 chunks, complex mesh:


16x16 chunks, optimized mesh:


Creating the optimized mesh takes 2-3ms. I mean just the calculations to get vertices and triangles.

 

32x32 chunks, complex mesh:


32x32 chunks, optimized mesh:


Creating the optimized mesh takes 20-30ms, but who cares as it is in another thread.

PS
A little description of how to create such meshes - http://forum.unity3d.com/threads/63149-After-playing-minecraft...?p=687911&viewfull=1#post687911

 

Also I thought about moving the world in opposite direction when the player moves. The current state of my engine allows me to teleport myself in any part of the world, so I've made some experiments:

50 000m from the center of the universe: everything is still fine.
100 000m: some barely noticeable lines between meshes/chunks.
500 000m: noticeable gaps between meshes, the camera and the meshes shake when the player moves or rotates.
1 000 000m: some gaps are ~5-10cm wide, the camera and the ground shake like hell when the player moves, just like an earthquake.

Even if a player with inquisitive mind puts a brick on his keyboard and leaves it for a while, it will take him more than 3 hours to go 50km in one direction from the center of the map. I think I will not bother myself with moving the world, I'll just recalculate it every time the player loads the game.

 

Yea, this happens to in minecraft. Its just because of overflowing variables. I think its better because it adds that little bit of oddity when you travel VERY far. Btw, any tips on block placing? I am also working on a light algorithm.

 

placing = raycast plus mouse buutton press.. and simply what you do is you just take the hit.point and on that place change the block to 1--dirt.. or whatever, and light is pretty simple, but kinda hard to code.. what you need is that if block is under the sun change it's light to 1 and if not take a light of a light block that is next and lover it...