Another Scale: Differentiating from MineCraft

eleazzaar

Member
Contributor
Art
I probably missed some, but every inspired-by-minecraft voxel game i've seen uses the same scale. For them all 1 cube is 1m3.

While this may be mathematically nice and neat, measuring stuff in even meter lengths isn't a killer feature of voxel games-- so i must assume that most everybody is blindly copying this paradigm without considering alternatives.

This scale has some negative consequences. To move around on anything but a flat plain you must hop everywhere. Exploration means constantly slamming the spacebar. To make blocks you can walk up, half-blocks and stairs were introduced, which caused trouble with targeting, lighting, and interact weirdly with fluids.

Alternatives:

1) Make the fundamental building block of the world, not cubes, but half-cubes (i.e. 1 m wide, .5 m tall).
To maintain the general speed of excavation, these blocks should be harvested twice as fast.
Pros:
  • * More naturalistic landscapes
    * Half-blocks can be used everywhere of any material, without weird limitations
    * Thus more detailed buildings
    * No need to Jump everywhere
Cons:
  • * Measuring by meters: Worlds would take up 2x the disk space, or only 1/2 as much could be held in memory at a time
    * The half-block shape may be a little weird for some uses.
2) Scale the cubes to 2 feet per side.
At this scale people would be ~ 1 block wide and three blocks tall, so entities could automatically walk up (without jumping!)any 1 block high obstacles. Jumping could get you up a 2block high obstacle. Crouching could plausibly get players through 2 block-high tunnels.
Half-blocks and stairs could be omitted.
Pros:
  • * More naturalistic landscapes
    * No need to Jump everywhere
    * More detailed buildings
    * Everything is still a cubes
Cons:
  • * Measuring by meters: Worlds would take up slightly more than 2x the disk space or a little less than 1/2 as much could be held in memory at a time
3) Why don't you just make the world up of .5 m cubes? Because that would require 8x the disk space, or only 1/8th as much could be held in memory at the same time. That is, i think too much a price to pay.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
I've wondered about something similar, tho mainly I thought we could do smaller / custom blocks where it would make sense (hills, etc). But then admittedly I didn't think a whole lot about it :)

Slopes have also come up a time or two. Dunno how that would impact the landscape.

I like the idea of making the player just a little bigger vs the cubes. Could even do that without breaking with the 1 cube = 1 m3 "standard" - just make the creatures bigger :D

I'm not sure exactly what that would involve tho. Moving the camera viewpoint is probably easy, but changing the collision expectations? IIRC even stairs don't currently "work"
 

eleazzaar

Member
Contributor
Art
Cervator said:
I like the idea of making the player just a little bigger vs the cubes. Could even do that without breaking with the 1 cube = 1 m3 "standard" - just make the creatures bigger :D
Yeah, the crux is the player's size compared to block size. That's what the player will generally use to get a feel for the scale of the world anyway.
 

ironchefpython

Member
Contributor
Architecture
I prefer leaving the scale a 1m, and giving the player the option to build their own block meshes out of sub-blocks. (perhaps even with angled planes for slopes and such)

But I do think your idea has merit, and at some point a game with smaller voxels might be interesting to play with. It seems to me more like a Terasology 2.x feature rather than something we want to focus on right now.
 

eleazzaar

Member
Contributor
Art
ironchefpython said:
But I do think your idea has merit, and at some point a game with smaller voxels might be interesting to play with. It seems to me more like a Terasology 2.x feature rather than something we want to focus on right now.
Why? Either of the ideas above would replace the need of implementing half-blocks and stairs, and avoid the awkward edge cases those blocks have. Unless you consider half-blocks and stairs a 2.0+ feature, it makes sense to do this sooner rather than later. Unless, of course, it is decided that doing things like minecraft is better.
 

woodspeople

Member
Contributor
Design
I like the idea of half-scale blocks compared to Minecraft. Stairs are a pain, and they are only one of several possible variants, which mods have addressed (RedPower for example has dozens of types of sub-sized blocks). This seems like something easy to implement/change now, hard to change later. It's also an early differentiator in terms of drawing more poeple in. It would certainly draw in more people who like to build things (cough cough undo cough cough). And like eleazzaar said, it would remove work in the long term, not add it. It would also make my trees cooler, which I hope I see someday in TS. I wish I had time to port my code to Java right this moment, but I must not do it while more pressing things remain.
 

ironchefpython

Member
Contributor
Architecture
eleazzaar said:
Why? Either of the ideas above would replace the need of implementing half-blocks and stairs, and avoid the awkward edge cases those blocks have. Unless you consider half-blocks and stairs a 2.0+ feature, it makes sense to do this sooner rather than later. Unless, of course, it is decided that doing things like minecraft is better.
I was assuming collision meshes that are based on the rendering mesh would be a 1.0 feature. This would allow steps, slopes, grates, etc.

Native half height blocks would remove the need for Minecraft slabs, but it doesn't seem to be the ideal solution. 2/3 sized blocks is simply trading memory to solve a jumping issue without making slopes.

Again, I think your idea has merit, but I don't think either of your suggestions would remove the desire to have blocks that have a custom rendering and collision mesh, and once those blocks exist, that solves the problem of jumping. And changing the scale at which blocks are rendered means in the best case we'll need to have double the block ids for things that have complex textures like furnaces, and in the worst case all of the existing assumptions about behavior and function need to be thrown out. (For example, should doors now be 1x3 blocks or 2x3 blocks? And how would 2x3 doors even work?)
 

B!0HAX

Member
Contributor
World
eleazzaar said:
1) Make the fundamental building block of the world, not cubes, but half-cubes (i.e. 1 m wide, .5 m tall).
To maintain the general speed of excavation, these blocks should be harvested twice as fast.
Nice idea, my thoughts on this:
It would create better landscapes than the ones right now,
also tree growth would look nicer (whenever implemented).
Spacebar will be happier.
I imagine it will also be better for the pathfinding results.
Also those half blocks could be collected in stacks of full blocks...
If the number isn't even (contains x and half blocks) then the last block you place is that half block?
 

eleazzaar

Member
Contributor
Art
woodspeople said:
I like the idea of half-scale blocks compared to Minecraft.
Are you referring to #1 in the first post above, or #3?

ironchefpython said:
...2/3 sized blocks is simply trading memory to solve a jumping issue without making slopes.
They function as slopes. In a chunky voxel game that's mainly what counts.

ironchefpython said:
And changing the scale at which blocks are rendered means in the best case we'll need to have double the block ids for things that have complex textures like furnaces...
That's certainly something that needs to be considered. But i can't think of very many objects where that would be an issue. Furnaces, yes, and chests & pistons, and a few other of MC's more esoteric blocks (which might not be in TS). Bookshelves, ladders, fences, glass, brick, etc. could easily work as 1x1x.5 sized blocks, with no additional IDs. Almost anything could still work as a 2ft block.
I think it is safe to say that fewer additional block IDs would be involved than a even a half-hearted implementation of MC-style half blocks & stairs.

ironchefpython said:
...and in the worst case all of the existing assumptions about behavior and function need to be thrown out. (For example, should doors now be 1x3 blocks or 2x3 blocks? And how would 2x3 doors even work?)
For #2 above, doors can be 1x3. The player will just be closer to real human proportions-- i think it would be annoying if a player didn't fit in a sufficiently tall one block wide space. 2x3 doors could work as double doors-- two doors next to each other.

What else? There are probably other things either of the changes above would effect that i hadn't thought of.

B!0HAX said:
Also those half blocks could be collected in stacks of full blocks...
If the number isn't even (contains x and half blocks) then the last block you place is that half block?
Well, you would always want the option to build directly with the half-hight blocks, for detailed constructions. But it would certainly be nice to be able to place full cubes also to save time. I don't know what would be the best way to do that-- a key or button that toggles between building modes, or quick crafting that could be done to merge/split blocks from cubes to halves and back.


Other Pros:
* Sloped tracks and water flowing downhill would be more realistic with 1/2 slopes possible.
 

Immortius

Lead Software Architect
Contributor
Architecture
GUI
ironchefpython said:
I was assuming collision meshes that are based on the rendering mesh would be a 1.0 feature. This would allow steps, slopes, grates, etc.
We actually already have that to a certain extent. It is just the character controller has not been updated with step support. If you spawn a BrickStair block, you can stand on the step. But I do think we need a redo of character collision in general to support non-AABB collision - I was thinking of then adding sloped blocks and such.

The other question is really whether it is too fiddly having half-height blocks, although you could make composite blocks the normal building block still.
 

eleazzaar

Member
Contributor
Art
Don't forget the function of a world isn't only to contain linear distance, but detail.

If memory usage was the only concern, 2x2x2 meter blocks would be superior to the 1x1x1. But having more terrain, but less interesting terrain isn't a win.

I don't pretend to know certain weather a particular type of smaller world with smaller blocks would create a more satisfactory experience (assuming memory usage is constant), but it will at least partially make up for it.

Immortius: your post looks unfinished-- you quoted iron without quote tags and didn't follow that with anything
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
I do like the idea of being able to include more details in the world, especially for organic growth. I figured we'd just do custom blocks (custom meshes smaller than a normal block, I guess) for organics within a world with a larger standard cube.

I wonder at what point we'd risk moving from a "retro 8-bit style" to "well they're trying to make it look good, but now it doesn't have the retro feel, and hardly arrives at Skyrim in return"

It looks a bit like Cubeworld uses the half-slab approach (climbable, anyway), yet also has small creatures. Or it is just less steep in general (our mountain biome tends to be kinda sharp)
 

woodspeople

Member
Contributor
Design
Are you referring to #1 in the first post above, or #3?
Number one I think. It is not perfectly predictable that worlds would have to get much larger, because there are psychological as well as algorithmic aspects to what might happen. I feel in MC like sometimes I fly up just in order to "see more" but not necessarily more land - more detail. I've noticed on videos that a lot of people do this, either fly or climb to get a view. I wonder if the 1m cubes and 2m tall player fall below some kind of interestingness threshold; you just can't help wanting more. It feels intuitively that if the person was taller or the blocks at least slightly smaller the experience would be less frustrating (as in "can't see, must get to place where I can see"). It is possible that if there were slightly more visual detail people might not need to make their words larger, so the net effect might be similar. Just spitballin' here. If it were easy to try out in testing it would be worth testing. But it may not be easy, and that's easy for me to say isn't it. ;)

And hitting that space bar to climb is a royal pain.
 

metouto

Active Member
Contributor
Art
As I said in an way earlier post somewhere ... some of the games I have played when you use the space bar to jump you keep jumping as long as the space bar is held down .... so ..... one held down space bar could = 1,000 jumps :)
 

eleazzaar

Member
Contributor
Art
Cervator said:
I wonder at what point we'd risk moving from a "retro 8-bit style" to "well they're trying to make it look good, but now it doesn't have the retro feel, and hardly arrives at Skyrim in return"
Minecraft sized blocks correspond roughly to a single tile, in a retro 8bit game. I think you could shrink the fundamental size of the block until it corresponded to a pixel in an 8bit game before you started to loose that feel. In other words blocks 1/8th or 1/16 of a meter on a side. Blocks that small would cause other problems, of course.

I'd be more worried about loosing the 8bit aesthetic with the introduction of sloped or angled blocks, though i think the main thing that creates that feel is the lack of curves, and the low-res textures.)[/quote]


woods people said:
...It is not perfectly predictable that worlds would have to get much larger, because there are psychological as well as algorithmic aspects to what might happen. I feel in MC like sometimes I fly up just in order to "see more" but not necessarily more land - more detail. I've noticed on videos that a lot of people do this, either fly or climb to get a view. I wonder if the 1m cubes and 2m tall player fall below some kind of interestingness threshold; you just can't help wanting more. It feels intuitively that if the person was taller or the blocks at least slightly smaller the experience would be less frustrating (as in "can't see, must get to place where I can see"). It is possible that if there were slightly more visual detail people might not need to make their words larger, so the net effect might be similar. Just spitballin' here. If it were easy to try out in testing it would be worth testing.
I think that's a well-expressed point. Sometimes, when you are close to the blocks, MC is just too un-detailed-- it feels sorta like the world is out of focus. I find my self trying to get away to try to see things from a more distant vantage point too. And in general i've noticed that people usually build thing out of scale to their avatar -- i.e. an ordinary house has a celling 4 or 5 meter high.

I have no idea how hard this would be to test-- but this is one of those things were a minute of play testing would easily be worth an hour of speculating/arguing/guessing. To test #2 (2ft cube blocks) all you would have to do (more or less) is get the player to hover 1 block-hight above the ground


metouto said:
As I said in an way earlier post somewhere ... some of the games I have played when you use the space bar to jump you keep jumping as long as the space bar is held down .... so ..... one held down space bar could = 1,000 jumps :)
Yeah, it's quite possible to deal with the jump everywhere problem by just changing jumping, and nothing else. I had a mod for MC once where you could climb up any 1 block elevation just by walking towards it. But then you couldn't make walls that you could see over, but not accidentally walk over (unless you used fences).

My purpose in mentioning the jumping problem isn't that changing scale is the only way to fix it, but that that it solve the problem very nicely.
 

ironchefpython

Member
Contributor
Architecture
eleazzaar, you've provided a couple great ideas, and provided a compelling apologia. My only critique at this point is your suggestions about changing block size are a fundamental change to the Minecraft-esque gameplay that many of us are assuming is the bedrock of the game we are building.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
ironchefpython said:
eleazzaar, you've provided a couple great ideas, and provided a compelling apologia. My only critique at this point is your suggestions about changing block size are a fundamental change to the Minecraft-esque gameplay that many of us are assuming is the bedrock of the game we are building.
I'm confused now - does that refer to the potential of a 3-cube tall player or something vastly different? I don't think we're going to 1 pixel blocks or anything :)

(I too wonder if slopes will do more than any radical cube resizing)
 

overdhose

Active Member
Contributor
Design
World
GUI
slopes I've seen in minecraft already, there is a mod for that. Makes houses and bridges and the like look little better, that's about it

The question is : will you use slopes in terrain generation? because that will make a big difference.
 

eleazzaar

Member
Contributor
Art
ironchefpython, Immortus:

Since "Slopes" and or "blocks or arbitrary shape", (i'm not sure if these are the same, difference, or overlapping alternatives) seems to be the main alternative to some form of slightly smaller blocks--

It would be nice to get a more detailed description of how these alternatives would play out. 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.
 

ironchefpython

Member
Contributor
Architecture
eleazzaar said:
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%).
 
Top