next »

[Christian Knudsen]

Could this maybe be some kind of Rubik's Cube game where you walk around the environment, rotating sets of blocks to unlock new areas and stuff? Some kind of first person puzzle block game? But where the environment has trees and houses and stuff instead of being completely abstract?

[moi]

the "cube engine " name is already taken though

[penguins]

moi: I agree with the name. Rest assured, I am thinking of a cool/actual name.

Chrknudsen: Have you seen

? Is it similar to what you are saying? That would be interesting. Something like that old game labyrinth except in 3d.
 
Kada2k9: Thanks :D

Carrie Nation: I would be a lair if I said Minecraft didn't inspire me, thanks notch. Pixel art for the 21st century  .


Ok, So more about what I was thinking for the game. I think i have narrowed it down to a 3rd person shooter of sorts...

Each player would be a 3x3 cube. I am thinking multiplayer but i am not sure how many players per game. The world would be made up of terrain, then on top of that terrain there would be other cubes, npc. These cubes would act a certain way that varies from game to game and possibly by color. The job of each player is to spot the other player and to shoot him. Players can either shoot or run (double speed or something). Players can't shoot while running. Firing will be slow enough to make running viable, ie sniping from too far of a distance wouldn't work. First player to hit the opposing player wins. To win one would have to blend in and act like the other npcs.

I wanted to add power ups too that are placed randomly around the map as well. These would encourage exploration and reduce the stale mate factor. One I have thought of would be a permanent ward type thing that makes a giant cube around the area where you place it. This would beep or something and point out of an enemy player is inside. This space controlling effect as well would reduce stale mate.

Does that sound fun to anybody?

[gimymblert]

Thanks for the tips. I have read a quarter or so (was getting to complicated ) of the article and understood some of it. It was an interesting read.

What I am currently doing: 32x32x32 pixel chunks. (the image you see is 8 of those chunks,2x2x2) Rendering each one as a manual object. I can see how storing data into that type of structure would help a lot for ray tracing and such. I should probably implement a SVO look up in each chunk for that. Is 3 mirrors of the same data bad lol.

The only problem i see with it is it limits efficiencies with odd dimension sizes. I can do 64x64x64 then 128x128x128 then i have to make the gigantic jump to 256 which i think is going to be super overkill. I like with my current system being able to have storage for a 128x96 map for example.
Thanks for the input :D

It works for odd data (you can use a set of root node) too and the hierarchical structure allow for efficiency.
Sparse voxel octree is designed for (streaming) very large dataset but can be adapted well to small (dynamic) dataset too.

But yeah it is not really needed for your project though.

[penguins]

That's nice and ya it is probably unneeded... But I still learned learned about a lot about voxels. :D Thanks.

Another quick update. Removed my own physics system in favor of Bullet. Bellow is a quick performance test to see how many npc are feasible.


Comments and crits welcome as always.

[penguins]

I have been fooling around with a procedural tree/forest. Not 100% wild about the trees, the top is a little too round for my liking. Procedural trees are harder than I thought..


Also ran into performance problems because of too many batches Currently i am fixing that and trying to think of a name.