Waterlimon

Dont make a limit to dig depth, but make it more realistic. In real life digging is slowww, you got to take the stone and dirt somewhere, have supports, supply of air, watch out for water leaking in and so on.

You should probably generate the physical object only.for the area near the player.

I think 1/8 blocks would make it too slow if you want a large world...

But it would be cool if it represented damaged blocks not as different texture but by making it look like theres chunks cut away.

Lets say it has the damage value, and based on that, if its damaged and youre close to it (!), it makes it look like a 3*3*3 chunk of blocks with some taken away depending on surroundings and damage (and different texturing based on block/damage)


If you go farther away it would just show it as a normal cube but different texture to represent damage.


Not sure if it could be done using shaders to make really deep looking holes and stuff, that might look better.

EDIT: random though, what it would look like if you used some nonlinear z division instead of a linear one? So that close objects get smaller slowly, but farther ones faster (so it kind of would represent some range with same precision and then quickly reduce precision over distance?)

Ideas for graphics:
-Fancy shader effects (bumpyish surfaces, glowing lights (HDR?), water effects...)
-Smoothed edges/corners for some block types, not for some others (dirt would be smoothed, rock not)
-Fog, not the distance based one but a voxel based one. Not sure if its possible. Like a sea might have a fog layer over it under certain conditions, but on top of a mountain you can see clearly. Maybe a low-resolution 3d grid with transparent surfaces, so in a foggy area it renders the low res grid as various densities and colors of fog? (idk, billboards?) It would look nice to stand on a mountain or high tower and not see any ground details, just tips of other high things (if its foggy weather i mean, maybe even fog producing things to make it harder for your enemies)


I think the greatest thing about voxel games is all the cool mexhanics/physics you can add. Air, fluids, pressure, heat etc. You should really mess with those lets say trying to add air pressure (10 different air types for different pressures? unless you want an air pressure value for every air block of course.)


If possible try to make the engine generate really high mountains, one of the reasons i find minecraft boring is that the terrain is too flat and everything looks the same. If there was a giant mountain that takes 30 mins to get over and its all snow and ice and i would freeze to death half way through, that would be awesome.


EDIT:

Oh and check out this in dev voxel game named "terasology", it had some cool graphics like better light effects and moving grass blades and stuff...

I would have hoped the physics and gameplay be more realistic. As in, placing blocks takes time, restraints on where you can place them, gathering stuff might not be possible due to environment (1000 tons of stone on top of the base of a castle, no mining castle base for you), limit to block carrying capacity.

Of course it would require stuff like carts to move blocks around, or on multiplayer other players or npc's to help you. I just thought the player has too much power in how he can edit the world, i want to be able to make a castle where people cant just dig in in seconds or make a pile of dirt to climb over the walls...

Your algorithm looks like it IS A* to me...

I dont think voxels should be used unless you want to represent a volume, meshes are just better for surfaces.

I have a container where elements might get moved around.

So, for the things iterating it the element points to the iterator and iterator to element so they can be updates when stuff is moved around.

However, i want only a single iterator to point to a element so each element only needs to keep track of and update a single iterator.

But since i want the user to have a nice object to iterate with, i create a class that redirects the commands to the previous iterator. (Is this a proxy?)


So it looks like

Iterator<->Internal iterator<->Container


Currently my container would keep the internal iterators in a vector and when it moves elements around it checks the internal iterator the element points to (index to the vector) and updates it.

The internal iterators are reference counted as there is only need for a single internal iterator for an element even if there are multiple readers. I thought that this also allows putting any kind of multithreading controls (lock thingies and stuff) into the internal iterators so it doesnt add to the size of the individual elements.



Is it ok to have the container handle both internal iterators and elements, or is there a way to separate them? Note that the nodes need to have an index to the internal iterators and the class which moves them around needs to cause the internal iterator to be updated somehow.

Also, what are these kinds of redirecting things called? (so i can index redirector[] with the same value even if the object it redirects to moves around)

I dont think you should make your own scripting language unless its purely for learning purposes, or if its a very simple one (where you call a few predefined functions in different orders or with different values). But if you need to do any logic or have more complex structures in the scripting language just use Lua or something.

You should probably use some GL_NEAREST (or something like that) for the full resolution tile, and some interpolation for the rest if thats possible (though i dont know if you should use nearest for those too) when setting the setting up the texture.

I dont really buy/play any 60 money-unit-costing games, but i feel like theyre kind of like interactive stories with the focus on great graphical quality, with the multiplayer part where youre supposed to grind for a few months before buying the sequel.

They are fun to play through. But as "interactive movies + some grind", theyre not fun after completing the story. I like sandbox games because you can feed your own imagination if the built in imagination food runs out. Modern games need more sandbox.

You can also use a x,y,z position.

so to know which child node to go to, you take (x[curDepth],y[curDepth],z[curDepth]) (component[depth] takes the depth:th pixel of the component) which gives you a bool,bool,bool which corresponds to 1 of the child nodes.

Though edd's way of having all of it in a single integer would probably be more space efficient if that matters.

You could have it like it is now (maybe some shaders to make it look 3D), and when you get closer use particles and fade the cloud texture away.

Maybe make it so that inside a single file, the nodes can be scattered all around, but they can also point to other files.

For example if you have a file containing the root and its possible child nodes, the child nodes could point to other files which contain their descendants (which might point to more files)

That might work. If you make the files small enough you could do it without scattering them all around the file but that requires moving all the nodes around in the single file when adding or removing nodes (might not be that bad)

Do you mean you have the angle of the sound (0-360) relative to the camera, but you want to convert it to how many degrees it is from the "directly in front" direction? so if its 90 degrees, it could be 90 degrees to the left or right?

Or what?