<\/td><\/tr><\/table><\/p>\nSlopes aren’t really a foreign idea to an octree-based world. Minecraft has steps, which are basically slopes for the purposes of blocking light (they don’t) and collision. I want to take this one further and make slopes a part of the natural landscape. Like a lot of the stuff with this project, I’m not sure how well this will work out. <\/p>\n
The trick here will be that the software needs to be able to look at a landscape and figure out which blocks should be turned into ramps, which ones should be turned into corners, which ones should remain cubes, and which way the slopes should face. <\/p>\n
First, I need to set some parameters:<\/p>\n
<\/p>\n
- \n
- Slopes should happen automatically.<\/strong> I’m picturing some sort of special block that has auto-sloping properties associated with it. For my tests here, I’ll be doing it on grass, but I imagine it would also apply to sand, gravel, and that sort of thing. I’ll be calling these blocks “soft” blocks. So now there are three states for a cube of space: It’s either solid (like stone) soft (like grass) or empty. (Like, air, see?)\n<\/li>\n
- No deep analysis.<\/strong> When analyzing which way to slope, individual blocks can only examine their immediate neighbors, and not look at more distant blocks. Two reasons for this: First, there’s a tiny bit of overhead to looking up blocks. Alone, it’s not a big deal. But if every soft block needs to look two or three spaces away, then we’re talking about a LOT of lookups. Also, if the orientation of a block can change based on stuff happening three blocks away, then this might lead to madness and confusion for a player. Example: You change\/remove a block in front of you, and 3 meters away a bunch of landscape suddenly changes. Yuck.<\/li>\n
- Soft blocks must be blind to the orientation of other soft blocks.<\/strong> I want to orient all soft blocks in a single pass. If block A needs to know what block B is doing (is it sloping away from me? Towards me?) then that means I need to do block B first. But what if B isn’t done yet? What if B is waiting on C? What if B doesn’t exist yet because it’s on the edge where terrain is still being created \/ loaded? Since we’re doing this with an octree, we can’t count on blocks appearing in any particular order. <\/li>\n
- These slopes are only for making hills.<\/strong> Walls will still run at ninety degree angles and we’re not going to slope ceilings. While it might be kind of interesting to make some kind of NURBS<\/a>-based scenery, that’s not what I’m after today. Still, that would make for an amazing experiment. It’s insane how, over a year after Minecraft became a mega-hit, we’re still not seeing more people at least play around<\/em> with these ideas. I think you could spend a year pumping out different octree-based cube prototypes and still not see everything this technology has to offer. I mean, check out Sea of Memes<\/a>, where Michael Goodfellow was remixing Minecraft like a DJ. You could read through that series and run off with half a dozen game designs.\n<\/li>\n<\/ol>\n
The solution I came up with is that the program will make one quick pass over the scenery. It looks for soft blocks. <\/p>\n
<\/td><\/tr><\/table><\/p>\nOverhead view. Green = soft blocks. Red=hard blocks. White = empty space. It looks like this:<\/p>\n
<\/td><\/tr><\/table><\/p>\nI apologize for how hard it is to make out shapes. This will stop being a problem once we have proper lighting.<\/p>\n
It examines each soft block. If there’s another block on top of it, it’s marked as solid. If it’s surrounded on four sides by other blocks (soft or solid) then it’s marked as solid. <\/p>\n
<\/td><\/tr><\/table><\/p>\nNow it runs through the soft blocks again, this time making them “lean” against any nearby solids. <\/p>\n
<\/td><\/tr><\/table><\/p>\nThis was kind of crazy. I spent a lot of time experimenting with rules for which blocks would slope, and under what circumstances. <\/p>\n
Sadly, I got pretty wrapped up in the process and forgot about taking screenshots, so I can’t show you all the ways that this went hilariously wrong and stupid and was broken in ways that I hadn’t even considered. Here’s one example:<\/p>\n
<\/td><\/tr><\/table><\/p>\nTwo opposing slopes wound up next to each other. The resulting gap in the scenery lets you see through the ground to the… lava. (Disclosure: Not really lava, from a gameplay perspective. I just re-colored my checkerboard base with a lava texture for fun, and found it was super-helpful in letting me spot gaps in the terrain at a distance.)<\/p>\n
Remember that when slopes are being created, they can’t query each other and see which way the others are facing, because those other slopes might not be in position yet. I could have it look for neighbors that have<\/em> been set, but that would create relationships that are difficult or impossible for the player to understand. You’d wind up with stuff like, “If you’re building on an odd-numbered block on the world grid then the south-most or west-most neighbor dictates which way the slope will go, while on even-numbered blocks you’ll get…” And so on.<\/p>\n
The upshot is that if slopes are decided by looking at neighbors, then a player would be able to build the same exact arrangement of blocks in 4 different places and end up getting 4 different results, depending on where their structures fell on the world grid and the powers-of-two scale. Madness. No, if this is going to work, then soft blocks have to make their decisions without regard to what other soft blocks are doing.<\/p>\n
Not to keep you in suspense, I do manage to come up with a working set of rules that produces slopes and (so far) doesn’t seem to leave holes in the terrain. The result is a set of rules that is so complicated I can barely follow them. If I have to come back to this in six months I’m going to hate myself. Here is my little test scene, now with slopes:<\/p>\n
<\/td><\/tr><\/table><\/p>\nHere is what that looks like in my example drawing:<\/p>\n
<\/td><\/tr><\/table><\/p>\nNote the block in column 4, row 3. That’s an inside corner. To give you an idea of the complexity involved, here are the rules controlling this block:<\/p>\n
- \n
- The northwest block must be empty.\n<\/li>\n
- The north and west blocks must be soft. (We can’t know which way they’re facing, but we know they’re soft.)\n<\/li>\n
- The northeast and southeast blocks must be non-empty. (Solid or soft.)\n<\/li>\n
- The east, south, and southeast neighbors must be solid.\n<\/li>\n<\/ol>\n
In code, it looks like this:<\/p>\n
\r\n \/\/The diagrams below represent this cell (center) and the cells directly\r\n \/\/adjacent to it.\r\n \/\/# Indicates a cell that MUST be solid.\r\n \/\/@ Indicates a cell must be non-empty. (Solid or soft.)\r\n \/\/x Indicates a cell that MUST be empty.\r\n \/\/? Indicates the contents of the cell are ignored.\r\n \/\/S The cell MUST be soft.\r\n\r\n \/\/ xS@\r\n \/\/ S\/#\r\n \/\/ @##\r\n if (cell[C_NORTHWEST].Empty () && cell[C_NORTH].Soft () &&\r\n !cell[C_NORTHEAST].Empty () && cell[C_WEST].Soft () &&\r\n cell[C_EAST].Solid () && !cell[C_SOUTHWEST].Empty () &&\r\n cell[C_SOUTH].Solid () && cell[C_SOUTHEAST].Solid ()) {\r\n facing = FACING_NW_INNER;\r\n \/\/etc... \r\n }\r\n<\/pre>\nYes, those comments are really part of the code. The code on lines 13-17 might be the most complicated conditional statement I’ve ever personally written. <\/p>\n
In practice, the world looks like this:<\/p>\n
<\/td><\/tr><\/table><\/p>\n(Ignore the stray single floating blocks. I built those as part of my testing \/ screwing around process.)<\/p>\n
<\/td><\/tr><\/table><\/p>\nWas it worth it? I dunno. It’s kind of different. I think the gameplay fares better than the visual aspect of the thing. You can run up and down these hills without needing to hop like Q-Bert, which makes getting around kind of fun. <\/p>\n
<\/td><\/tr><\/table><\/p>\n","protected":false},"excerpt":{"rendered":"Now that we have a world based entirely around the idea of cubes, you know what we need? Slopes. This is something that’s been on my mind for ages. I’ve run around the Minecraft landscape and wondered, “What would this look like if the cubes could slope to form beveled outlines?” Slopes aren’t really a […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[233],"class_list":["post-15892","post","type-post","status-publish","format-standard","hentry","category-programming","tag-octant"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/15892","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=15892"}],"version-history":[{"count":0,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/15892\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=15892"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=15892"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=15892"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- No deep analysis.<\/strong> When analyzing which way to slope, individual blocks can only examine their immediate neighbors, and not look at more distant blocks. Two reasons for this: First, there’s a tiny bit of overhead to looking up blocks. Alone, it’s not a big deal. But if every soft block needs to look two or three spaces away, then we’re talking about a LOT of lookups. Also, if the orientation of a block can change based on stuff happening three blocks away, then this might lead to madness and confusion for a player. Example: You change\/remove a block in front of you, and 3 meters away a bunch of landscape suddenly changes. Yuck.<\/li>\n