Another Scale: Differentiating from MineCraft

[Cervator]

And the nice thing about the block ID is that since it is never hard coded (other than Air, anyway, at 0) you could keep going way beyond the 65k unique identifiers in the development universe around the game, yet still be okay since you're not likely to have every single mod ever enabled all at once.

Still, there are probably some ways we might end up inflating the number of IDs too exponentially. Think stacks of ingots, if each different quantity stack takes its own ID, per material, per rotation (prolly only 2 here, at least). 25 different metals with maybe 12 ingots in a stack possible = 300 IDs just for that. Then add bookshelves, dynamically displaying the number of books, bookshelf itself could differ in material, 4 way direction, etc, with 20 different materials, up to 16 books, there's 20 * 16 * 4 = 1280

But there's probably a way to convert some of those to a secondary lookup off a base ID if we really need to.

 

[eleazzaar]

i Can you make half-blocks and stairs and slopes of arbitrary materials? If so, does each have a unique block ID? And/Or does it require new block metadata? I admit i have a weak grasp on those technicalities, but it seems possible that arbitrary block reshaping would also have a significant memory cost.

As currently implemented, I believe each combination of shape, material, and orientation (for blocks without 3-axis radial symmetry) would require a unique blockid. As we are currently discussing changing the block id to a short (2^16), that would mean that if you have 100 different building materials, supporting slabs, inverse slabs, and 4 orientations of staircase for those 100 materials would consume 600 of the 65.535 possible blocktypes (or slightly less than 1%).

Thanks for the answer. I assume there's a technical reason (i don't need to know why), that ~ 65k was chosen rather than a slightly smaller power of 2?
If so, and if you move to a "short" id, then it would probably make sense to simply have a lot half-blocks or stairs or whatever, since IDs are not scarce. Assuming of course, world generation can understand how to use grass half-blocks and/or grass "stairs", and so on.

I take it, then that there is very little other (if any) metadata in a block, besides its ID?

Still, there are probably some ways we might end up inflating the number of IDs too exponentially. Think stacks of ingots, if each different quantity stack takes its own ID, per material, per rotation (prolly only 2 here, at least). 25 different metals with maybe 12 ingots in a stack possible = 300 IDs just for that.

Yeah, it would probably be better to leave ingots as items put in a chest, or forge them into a full block.

Then add bookshelves, dynamically displaying the number of books, bookshelf itself could differ in material, 4 way direction, etc, with 20 different materials, up to 16 books, there's 20 * 16 * 4 = 1280

Make bookshelves 2 sided -- like in a library. That way you only have 2 rotations to worry about. In most cases the opposite side, will be against a wall, so won't matter, but sometimes you'll want a library-type bookshelf look. 1 m is really too deep for only a single row of books anyway.

 

[Cervator]

Good point on bookshelves. Wonder how that would mesh with dynamically displaying the number of books in a bookshelf tho, if each side is unique. That might be overthinking it.

As for ingots in the world - we really want to see that happen for some goods, rather than just tons and tons of DF-style bins you need to look through to find out what they contain. Shouldn't be too terrible to support ingots for metals, bushels of produce, etc

65k - maybe just for the ease of using a short rather than get into bit manipulation. Considered a 12 bit option instead, in particular were we to try fitting some initial block metadata into an int (something like block ID, secondary resource counter, light value, block integrity - added up to 32 bit total). However, now we've talked about doing metadata for blocks instead to support modding more.

Currently there are a few bits of metadata, look in Chunk.java for the TeraArray and TeraSmart array definitions.

 

[Immortius]

Thanks for the answer. I assume there's a technical reason (i don't need to know why), that ~ 65k was chosen rather than a slightly smaller power of 2?

The easily available powers of 2 are 256 and 65k (and then some million). Anything else requires a bit of work and comes with a performance cost.

I take it, then that there is very little other (if any) metadata in a block, besides its ID?

There's a bunch of metadata on a block type, like whether it is solid or not, luminance, hardness, probably a couple of dozen. But that's per type so is only stored once. In the world we save light levels and an extra "state" value per block at the moment, and there's also support for more metadata to be stored on a blocks via entities - though that should be used reasonably sparcely.

Yeah, it would probably be better to leave ingots as items put in a chest, or forge them into a full block.

I think we can afford some amount of block variations to display quantity contained, but don't think in needs to have a 1:1 correspondence with the contents. Empty, Slight, Half, Very and Full variations would be enough IMO. Variations from 0->16 is overkill.

 

[eleazzaar]

OK, you guys almost had me convinced, but i was thinking about it today as i was doing some manual labor.

While "making tons of half-blocks, stairs, and maybe slopes" definitely has advantages, it doesn't really have any of these "Pros" i listed in the first post -- or if it does it has weird issues.

Pros:

• * More naturalistic landscapes
  * Half-blocks can be used everywhere of any material, without weird limitations
  * Thus more detailed buildings

So lets say you have half-blocks, stairs, and maybe slopes of every block type that could make sense. And you generate the world elevation with them-- so you get nice more gradually rolling hills, that you don't have to jump to climb. Then it's time to tall grass, flowers, mushrooms, and trees, etc. Oops. How do you add these things to half-blocks? Floating flowers and grass .5m above the ground's surface looks pretty odd.

So let's say you just constrain flowers, tall grass, etc to only grow on the full hight blocks. That would produce odd alternating bands, but suppose we ignore that. Then the player comes along to the side of a gently sloping sand dune. He wants to build a house there, so he tried to place a brick. Wuh? The brick block is floating .5m in the air. While there's a perfectly good reason for this-- the player was standing on a half-block, and there can only be one type of block per cubic "space", this isn't obvious looking at the hill, and it just makes the game feel glitchy.

Conclusion: Unless somebody has clever ideas that haven't occurred to me, generating the world with partial blocks is problematic, and possibly not even a net improvement.

I think we can afford some amount of block variations to display quantity contained, but don't think in needs to have a 1:1 correspondence with the contents. Empty, Slight, Half, Very and Full variations would be enough IMO. Variations from 0->16 is overkill.

Good Idea.

 

[Immortius]

Wuh? The brick block is floating .5m in the air. While there's a perfectly good reason for this-- the player was standing on a half-block, and there can only be one type of block per cubic "space", this isn't obvious looking at the hill, and it just makes the game feel glitchy.

Actually we would just prevent placement in that situation, or automatically convert the underlying block to a cube, but I understand your concern.

Changes needed in order to support 2/3rd blocks that I can think of - would just need to increase the player (and other entity) sizes, change what types blocks there are, change a lot of things into multi-block structures, ensure pathfinding works with those changes, and change the world generators to create the world in the right scale.

 

[eleazzaar]

Changes needed in order to support 2/3rd blocks that I can think of - would just need to increase the player (and other entity) sizes, change what types blocks there are, change a lot of things into multi-block structures...

Um, like what? Doors and beds are already multi-block, so you need a 3rd texture, but not much more complexity.

Furnaces and workbenches aren't usually 1m cubes in real life-- usually much bigger. I don't think believability is much more injured by making them 2/3rd m cubes. Even if you want those bigger, those are just 2.

Torches, levers, ladders, windows, plants, flowers, pistons, fences, cakes, cacti, chests, etc work as well or better smaller.

Minecarts and tracks would probably need to be multi-block-- that's probably the worst part.

 

[Immortius]

Um, like what? Doors and beds are already multi-block, so you need a 3rd texture, but not much more complexity.

Ok, maybe a lot was the wrong phrase. Some things at least. Not making a big deal of it, just enumerating the considerations. It is almost something that could just be modded in without any change to the engine.

 

[dei]

Then the player comes along to the side of a gently sloping sand dune. He wants to build a house there, so he tried to place a brick. Wuh? The brick block is floating .5m in the air. While there's a perfectly good reason for this-- the player was standing on a half-block, and there can only be one type of block per cubic "space", this isn't obvious looking at the hill, and it just makes the game feel glitchy.

You are assuming that the whole world is built out of half and full blocks right? You make this variation of two block types to save space when persisting the world. What if we persisted the world in half and full blocks but in-memory or only for building/mining the world only consists of halfblocks. Then you only have to ensure that halfblocks that belong together (like flowers, furniture) are built and mined only as one unit.
This could be taken even further and the whole world could be compressed into superblocks (block-type: earth, from1,1,1), to3,3,4)) to persist. Speaking of the MC worldgenerator (generates big coheering masses of stone, earth and sand) we could save around 1/3 of memory.
What problems would arise from such a "halfblock only world"? Assuming the worldgenerator leaves full blocks together and smoothens the terrain with half-blocks on the outer sides so compression is possible (persisted memory usage would be around less than 1/5 higher than now)...

 

[Cervator]

I believe using octrees came up quite a while back, but would trade a memory issue for a performance issue. Currently I think we're more constrained by performance than by memory.

I personally like the idea of making the player a little bigger if we want to scale differently, then just break with the tradition of some single-block "things" in favor of multi-block - I sort of think we should do that anyway

 

[dei]

Making the player bigger is memory-wise the same as making the world's cubes smaller but in all 3 dimensions, alright?

That "player growing" would fulfill our target to make jumping and hills smoother OK, but we don't want to crack a nut with a sledgehammer: We only need smoothing in a vertical dimension, so shrinking blocks to half of their height would do the trick and consume 1/4 of the memory of the "2 times bigger Player" solution.

So why should we shrink the two other horizontal dimensions too? To make mountain-Peeks with a surface smaller than you need to stand? To force the player to bulldoze/level the land before he can build something/place a stove...? etc.

Or is it just the datastructure where the blocks have to be absolutely cubic (I didn't read through the implementation)?

 

[Cervator]

My main concern with half-blocks is that thing about full-blocks floating half a block up in the air - although, come to think of it, in a half-block world those are full-blocks and anything that was previously a full cube is now two half-blocks anyway. So there wouldn't be a problem building on half-blocks after all.

I'm not sure if we have any quirks in the system that relies on the blocks being perfectly square. Other than perhaps the block textures themselves - if you half those to 16x8 we might end up losing level of detail on textures to gain level of detail on world shape. If you squish them and simply paint on a 16x8 space they might look funny instead.

Dunno if any of the fancy shader tech relies on perfect squares.

I also don't think we'd double the player size. 1x3 sounds reasonable

 

[Immortius]

A 50% increase in player height, taking it from ~2 blocks to ~3 blocks. With a presumed increase in width to a bit over a block, unless we have a tall-thin player race. Reasonably manageable. Doors would be a bit interesting (they'ld probably need to be 2x3), but still achievable. Should be noted this results in a bit over 3x memory required for a portion the same effective sized as a current portion of the world. Compared to the 8x memory required for a full halving of block scale.

Having all blocks as half blocks doubles required memory due to needing twice the blocks for the same effective height. And unlike keeping blocks square, would require a lot of things to be multiblocks.

Textures shouldn't be a problem, just keep them square and have the block shapes map their sides to half of them.

The big problem with halving blocks just on the vertical is it only helps for low-gradient parts of the world. A 45 degree slope would still be unpassable as you would have double-stack of blocks followed by double-stacks. Keeping to square blocks of a steppable height and 45 degree slopes can be climbed. Also I feel they're less nice to work with from a player perspective.

As for what all these memory multipliers mean... At the moment it takes 3 bytes to represent a block. 1 byte for the Block type (0-255), 1 byte for lighting (sun 0-15, other 0-15) and 1 extra byte for state (used by water I think?). A chunk is 16x256x16. On Ultra viewing distance, 32x32 chunks are displayed around the player - and there can potentially be multiple players some distance away, each requiring 32x32 chunks maintained around them. So that's ~200MB per player, ignoring memory used for other things (entity systems, mesh in memory, physics system, sounds, etc), or that we'ld want more chunks than just the visible in memory.

Increasing the number of block IDs to 64k increases block size by 1 byte, so ~250MB per player. Scaling blocks are straight multipliers, so half-height blocks takes us to 500MB, 2/3rd blocks takes us to 750MB, and 1/2 blocks takes us to 2GB. Of course, if we don't bother extending the size of the world with a change it doesn't result in extra memory usage - which may be possible in the 2/3rd block size case.

This is also ignoring potentially changing to having 3 dimensions of chunks in the future.

 

[dei]

So there wouldn't be a problem building on half-blocks after all.

Absolutely my words .

Other than perhaps the block textures themselves - if you half those to 16x8 we might end up losing level of detail on textures to gain level of detail on world shape.

Since when textures in Terasology's or MC's terrain were really detailed? Dirt looks like dirt and stone like stone, irregardless if you have a 1/2 m block or a 1m one. (I'll try to compile a comparison in blender next week) For really detailed stuff like stoves, bookshelves etc. we have special block-sizes anyway. So I don't see any problems here.

Dunno if any of the fancy shader tech relies on perfect squares.

Can anyone comment on this?

I also don't think we'd double the player size. 1x3 sounds reasonable

Why enlarge the player? We would have to dig bigger shafts for it and without machine-gun . IMHO this would be more a thing for a mod/game-mode than for core and wouldn't solve the jump issue which for me is a rather big funkiller in MC.

 

[Immortius]

Why enlarge the player? We would have to dig bigger shafts for it and without machine-gun . IMHO this would be more a thing for a mod/game-mode than for core and wouldn't solve the jump issue which for me is a rather big funkiller in MC.

It is effectively the same as reducing the block scale. And switching to half blocks isn't any different - you'ld have to mine twice as much to dig downwards. It does fix the jump issue too, since you'd just set the step height to a single block's height for the enlarged player, which would hopefully appear to be a reasonable step height.

 

[eleazzaar]

Why enlarge the player? We would have to dig bigger shafts for it and without machine-gun . IMHO this would be more a thing for a mod/game-mode than for core and wouldn't solve the jump issue which for me is a rather big funkiller in MC.

Presumably if we make the player larger relative to blocks (or the blocks smaller -- same difference), we would reduce the time it takes to excavate blocks proportionately, so the player wouldn't need to spend more time to dig the same sized tunnel (relative to the player's own size)

A 50% increase in player height, taking it from ~2 blocks to ~3 blocks. With a presumed increase in width to a bit over a block, unless we have a tall-thin player race. Reasonably manageable. Doors would be a bit interesting (they'ld probably need to be 2x3), but still achievable.

I wouldn't make the player wider than 1 block, so to mine you could have 1 block wide tunnels, rather than being forced to chop out twice as much. While this would be thinner than MC players, it is actually closer to real, average human proportions.

A 2/3rds m door is kinda narrow, at least by US standards, but not absurdly so. My fairly average-sized body can fit through such a door. I'd recommend keeping single-block wide doors. And allowing the player to build double doors (as in minecraft: two doors hinged on opposite sides of the doorframe that meet in the middle) if they want something wider.

To take off on a little tangent, it would be cool if doors could be built of an arbitrary number of door blocks (or at least a larger number). Any doors on the same vertical space would open/close together. So you could build short little "doggy" doors, or double player hight grand palace doors from the same block.

Should be noted this results in a bit over 3x memory required for a portion the same effective sized as a current portion of the world

Sorry, you are right-- my original math was wrong.

Having all blocks as half blocks doubles required memory due to needing twice the blocks for the same effective height. And unlike keeping blocks square, would require a lot of things to be multiblocks.

Maybe. But it wouldn't require multi-block mine cart tracks, which probably means half-hight blocks vs 2/3rd size blocks are about equal in that respect.

The big problem with halving blocks just on the vertical is it only helps for low-gradient parts of the world. A 45 degree slope would still be unpassable as you would have double-stack of blocks followed by double-stacks. Keeping to square blocks of a steppable height and 45 degree slopes can be climbed.

In reality, a 45º slope is pretty difficult to walk up (depending of course on what it is made out of, and weather there are hand-holds). I don't think it is a bad thing if they are harder to navigate, though likely the player will still be able to hop up that far.

Of course, if we don't bother extending the size of the world with a change it doesn't result in extra memory usage - which may be possible in the 2/3rd block size case.

With a 2/3rd block world we may be able to reduce movement speed to ~ 2/3rds. So an island with the same number of blocks will feel just as big -- it still takes 2 mins to walk from one end to the other-- even though it is by linear measure (if the player took the trouble of counting blocks, which is unlikely) 2/3rds as long.

And in the case of a half-hight block world, you can have worlds of the same size, for the same memory, if you limit the hight to 128 meters, rather than the 256 meters as it is currently. (unless you have some clever way to make big empty areas of sky take up less memory)

 

[glasz]

Playing terasology it seems that the generated world is clearly on a bigger scale than in Minecraft. So for me it is possible to envisage a change of scale that makes the player twice as tall as in minecraft, in terms of consistency. Thus said one reason to want such a change would be not to have to jump every time the ground level change. I'm guessing if a scale effect is applied to each change of level that doesnt exceed 1, only a slight adjustement in the height of the camera could be enough.

 

[Cervator]

Here's a fun little devil's advocate bit I just thought of - if we change the scale around, so you can walk onto something 1 block high - would the player ever need to jump for anything?

With half-height-blocks you probably would, but scaling the player up might put you where 1 block is walking, 2 blocks is too tall?

I've been hesitant to go with anything not perfectly square as I figure there'll be ripple-effects somewhere. But that does seem to be one advantage I haven't thought of before.

 

[eleazzaar]

Here's a fun little devil's advocate bit I just thought of - if we change the scale around, so you can walk onto something 1 block high - would the player ever need to jump for anything?

Well jumping across pits and so forth would always be useful.

With half-height-blocks you probably would, but scaling the player up might put you where 1 block is walking, 2 blocks is too tall?

If by "too tall" you mean for an average person simulated with strict realism, then yeah-- though the average person wouldn't be stopped by a wall ~ 2/3rds their hight. Assuming it is nice and flat on top. You would use arms to assist your jump. (though animating that should probably not be a first priority)

Is there any particular reason the player should be limited to the physical prowess of the average person?

Another nice jumping mechanic which could be applied here is what i call "scrabbling". If you jump at a ledge, but don't get quite high enough, (say you miss by 1/2 a block vertically), it lets you up anyway-- simulating the character scrabbling at the ledge, or maybe tucking up their legs to clear.

 

[Immortius]

Another nice jumping mechanic which could be applied here is what i call "scrabbling". If you jump at a ledge, but don't get quite high enough, (say you miss by 1/2 a block vertically), it lets you up anyway-- simulating the character scrabbling at the ledge, or maybe tucking up their legs to clear.

Ah yes, I've always known that as mantling (from Thief). I've implemented it in the past, can only be easier in a block-based world.