Minecraft inspired world generator.

Game Engine Works in Progress and Game Demos
21

Ah I see what you mean.

So are you saying I should generate my massive array in the beginning? Or generate a top layer array and then whenever something is destroyed it magically generates a new block at random and adds it to the array?

The one flaw with this idea is the idea of having caverns. It means that if I were to spawn a cavern under a block that was destroyed it would mean generating a good thousand or two blocks at the drop of a hat.

Not a bad idea though, I may play around with that idea.

22

@Siegel: Sounds promising, performance should benefit greatly with those optimizations.
@-[Killer]-: If the player is the only one that can destroy blocks, than you can update only 4 blocks around that destroyed block to check if they should become visible.

23

@Killer - I did watch the video, I just didn’t know what it was doing. From the video, I thought that it was creating the blocks inside the cube when you (I assumed) hit a key, not just create the objects inside of the culling cube. In any case, it’s looking good, now that you have that figured out.

@laxwolf - No, voxels aren’t in 2.5 (though that would be pretty nice). They’re actually just cubes - you make up a shape out of cubes. You could think of a voxel as a simple pixel, and you draw in 3D using those cubes. An example is this video (which I won’t embed here since it doesn’t have anything to do with Killer’s generator).

The BGE isn’t fast enough (or actually made) to handle drawing voxels properly, rendering them in volumes, rather than by surfaces, but for my purposes, I liked it. EDIT: Of course, my version is far, far simpler than that video, with not nearly as many voxels. It can handle a few thousand, maybe? I’m not sure.

EDIT 2: @Killer - Perhaps you could spawn ‘cavern air’ in the map dictionary. If air is 0, then perhaps make -1 ‘cavern air’, which won’t allow blocks to be created in them.

24

Yes you should generate the entire map array at the beginning that way all the info is already there you just need to check against it.

25

@Siegel: I don’t agree. If everything is generated randomly using the same base seed than there is no need to generate the whole array in the beginning. The array can expand dynamically.

26

Yeah this is true, one way I can think of to get around this is to do the check when you start breaking a block that way if the block you are breaking is about to reveal a cavern then you can start to slowly pre-load the blocks before you break through

27

Thing is if there is a fixed boundary then may as well generate the whole map array for storage so it can quickly be accesses and checked against rather than bogging down the system every time you want to read from the array. It wont take up much resources to store the array. I would only suggest expanding dynamically if you want an infinite sized map or a extremely large map.

28

@Siegel: Minecraft has infinite worlds and i thought Killer wants to recreate the same concept. Where is the problem with caverns? Why can’t they be generated like the rest of the map?

29

It’s not so much a problem generating them as it is worrying about CPU power.

If you’re having caverns generated on the fly, this means that in the 2 seconds it takes to mine a block you’re going to have to generate possibly THOUSANDS of blocks (if that block of rock is infact blocking a cavern). Therefore you may experience terrible lag for a few seconds and probably get to see blocks getting generated.

Not too efficient.

30

Done! I’ve now implemented the suggestion Siegel had about air. I’m now getting a solid framerate of 60 fps with a 32x32 grid (1024 tiles). Let’s try a bigger simulation…

With 4096 tiles (64x64) it plays obviously at 60fps when sitting still, during movement it drops to 15.

The problem is that it’s looping through both a positions list with 4096 entries in it (with every possible position) and checking that data against an array with the actual objects in it (which IS NOT 4096 big, it’s however many tiles were generated; yes including hidden objects.).

Any clue how to speed this up?

Edit: Oops I messed up my calculations. That is 32x32x10. So therefore it’s 10,240. And the 64x64x10 is actually 40,960.

31

I still don’t see how can you get a problem like that. If the player is in the midle of the big bounding cube, and you generate the world inside that cube when the game starts and than generate the rest as the player moves. You will generate any cavern when its inside the cube, but it will be invisible until you destroy a block that is blocking the cavern.

I am sorry if I am being stupid, sometimes I have to see a problem to understand it.

32

I have an idea, if you split that huge array in smaller groups you can than hide or show groups instead of every block in the array.

Edit:
For example, one group can be blocks that have pos.x between 5 and 20 and pos.y between 0 and 15.

Also you can group them by x and y coordinates so you will have an array of 1024 instead of 10240

33

What do you mean by group them by x and y coordinates? There’s 3 axis… XYZ. Therefore there’ll have to be 10240, because it’s 16x16x10.

34

If your looking for some way of “occlusion”, I made a similar thing to this a while back when I made my helicopter, I’ve put a video to see if you’d find it useful (It only displays blocks in a certain area, but the setup makes the “world” infinite).

Another thing I was going to implement was to find a noise algorithm to give some structure to the random blocks instead of using a purely “pseudo-random” generator, like perlin noise or something, but I didn’t think it’d lead anywhere, something to consider perhaps…

not a very good video tbh, but the blocks generator infinitely, if you think something in there might help you, just say…

35

couldn’t you limit the indices that you looping through to those within the boundary. Im not 100% sure why you are constantly looping through the array?

36

And how exactly can I do that?

In order to figure out what’s in the boundary I’m going to need to figure out first off what the hell is in the boundary. How else can I do that besides looping through and grabbing what’s in it?

Actually… I think I just had an epiphany. Excuse me while I go waste away my day in the blender text editor :smiley: see ya’ll tonight when it’s working flawless

37

if you are storing the actual objects into the array might i sugest you just store their names and use a getObject(name) function to gain access to them. Cant wait to see what you come up.

38

It doesn’t need to loop through both if you store the positions of the tiles logically. What I mean by that is like this:

The way you’re doing it, to my understanding, is that you simply store the positions of the tiles in an array, and then check those positions against another array with the actual objects to find them. What if you store the objects where the positions say they are? Like:


positions = [ [0, 0, 0], [1, 0, 0], etc. ]
objects = [ 
[
[
Tile,   #0 (X-axis) - the first tile from above
Tile,   #1 (X-axis) - the second tile from above (positions)
] # 0 (Y-Axis)


] # 0 (Z-Axis)

]

This way you could use the positions as the indices to store the data.

However, a much better way would be to just use a dictionary to store the positions and objects in the same place -


cubes = dict({
[0, 0, 1]:Tile
[0, 0, 2]:Tile...     # In this case, 'Tile' refers to a pointer to the actual tile object.
})

With a dictionary, you can find the tile knowing the position, or the position if you know the tile (either using the tile object’s position property, or by going backwards in the dictionary. The Python help file goes into detail about going about this backwards). Also, you can dynamically add tiles to the dictionary, and it doesn’t matter where they’re added - you can easily loop through each occurance of the dictionary.

EDIT: I would go for the dictionary route, as it’s far easier to look at, and far easier to deal with.

EDIT 2: I was going to say that you could use a Near or Collision sensor, get all of the hit blocks, and display or hide them that way, but that would kill physics, even if the blocks were static ghost actors.

39

Actually I’m using a dictionary, I’m going to be putting an alpha version tonight (most likely). So look out for it :slight_smile:

40

Check out the diamond square algorithm for generating hight maps.

Also, you need to create chunks. Say an 8x8 region is a chuck. Don’t check distances to each block rather check distances to the chunks.