Another Scale: Differentiating from MineCraft

[Cervator]

Oh, ya, jumping across stuff, that works too. Never really had to do that much, but maybe we can allow the player to jump a little further than in MC to highlight it

I like the idea of scrabbling/mantling. Especially if it is easy to implement. And if a player is actively hit while doing that, make a chance of the player falling

 

[overdhose]

that big grin looks... spiffy
I agree it would be nice, but a little animation would be nice if someone has time / knowledge how to do it.

 

[overdhose]

how bout that...
according to this http://www.urbandictionary.com/define.php?term=spiffy I even used the word entirely as intended

 

[mkalb]

At the moment a block has the size "1" and the player is almost 2 blocks tall.
This is similar to Minecraft.

I would like to test smaller blocks <=> larger players.

At the moment the block size "1" means about 1 meter.
I suggest that we change it. The new block size could be 0.65 meter and the player size 1.8 meter.

What do you think?

 

[Skaldarnar]

I would like to try that out... Not sure if it will work out perfectly (you will have to throw away your minecraft habits somehow) and if the world will look completely rounded, but hey, I would give it try!

 

[aherber]

Although shrinking the cubesize will improve the graphical detail this comes with a high cost. If you you half the cube size (which comes very close to a cube size of 0.65) the number of cubes that needs to be rendered and stored are 4 times bigger. So this needs 4 times more ram then the current solution and 4 times more cubes need to calculated when generating the world. (Im not sure about the performance implications on this part). I would rather suggest the possibilty of using some smaller cubes on the surface of the world to increase the optical diversity. Althoug i dont know if storing additional informationen for the size of the cube (like the centerpoint for example) is feasible given the current byte structure for storing the blocks. I dont think it is possible without increasing the number of bytes used per block, but there may be some ways around this that im not aware of rigth now.

 

[mkalb]

I searched the code but I didn't find the classes where I can change these parameters. Can somebody help me, please?

aherber: Yes, the performance and memory will be a problem.

I don't like to jump over a 1 meter high block. That is nonnatural.

 

[basilix]

I have a pentium 4 E7400 cpu, 4gb ram and a hd redeon 5750 gpu. I know it isnt much but it lets me play new games with pretty good(allmost high on all settings) performance. The thing is i can only play terasology with lowest settings otherwise i get low fps...

My point is lets not do anything that will reduce the game performance
I know its not realistic to jump 1 meters but come on man its a world made of blocks

 

[Immortius]

8 times more, actually. Assuming you double the number of cubes vertically to maintain scale.

 

[Cervator]

Magic thread merging power activate! We had an extensive thread on this topic already

 

[mkalb]

Thank you Cervator
I searched the forum but didn't found this thread.

 

[Perdemot]

I would rather go for the miniblock approach of the scaling tool

 

[Cervator]

Thank you Cervator
I searched the forum but didn't found this thread.

No problem. The forum search seems arbitrarily weak sometimes. I wonder if it has been left like that to leave space for the premium search package you can buy from the company or something

 

[dei]

Tried to decrease the vertical block size too for about 5 hours of try and error and still no luck. Only smaller Rendering-Bugs arose. If someone is able to externalize the block dimensions to something which is easily changeable this would be really great! (perhaps with a comment which non-java files have to be altered)

If begla or Immortius could roughly guide me at the right spots in the code I could try to do this tonight by myself. So we all could experiment with block-dimensions...

 

[mkalb]

Immortius: My example has only a factor of 2.25 (=3*3 / 2*2) and not 8. A chunk has only 256 blocks (height).
But this is with the current performance and memory usage too much.

 

[Immortius]

I was assuming you would double the height of a chunk to maintain scale. But fair enough.

dei That is honestly a pretty big task. The world being a grid of 1 x 1 x 1 cells is an assumption built in across the board. The major involved systems are the chunk tessellator and physics integration, but also any system that converts from world coords to block coords is based on this (look for new Vector3i(_, 0.5f) and _.toVector3f()). This also feeds into the shapes, which are all defined within a 1 x 1 x 1 area and build the mesh and collider information that feeds into the other systems.

 

[mkalb]

Immortius: Thank you for the information. It is more complicated than expected.
I was hoping that I could test it quickly. But I let it now first.
Instead, I'll try a few ideas to reduce memory consumption.

 

[Immortius]

Oh, sorry. I intended to direct that second bit of the post to dei and his vertical scaling question. Uniform scaling is easy - you would simply change the scale of the player in the player.prefab (and maybe change some camera settings).

On the memory consumption, one though I had was instead of each block type having an unique id that is used across all chunks, each chunk could manage ids for its blocks individually. This would allow chunks to use different storage schemes based on the number of different blocks used in that chunk - if there are only 16, it could use nibbles, if there are 256 it can use bytes, for a small range over 256 it could use bytes with one id as a flag to look in an extension table. And if it uses more than that, it can use shorts.

Metrics on how many of each type of block occur in a chunk may also be useful - both for storage optimisation as well as gameplay.

Of course there are some costs in terms of complexity, and we'ld want to set up some performance tests to ensure the different modes don't have unwanted costs.

The idea occurred to me because with the recent changes to blocks, there is now nothing that cares about the actual underlying ids except chunks.

Keep in mind that we'll almost certainly want to break the current 256 block type limit in the future.